Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [git] Tags migrated from SVN

Hi Stephan,

regarding your first issue:

I ran into the same problem. The basic git branch-filter command loses all of your tags (i.e. leaves them untouched which makes them point to no-more-existent commits).

Though I haven't tried it yet, specifying an additional
--tag-name-filter cat
could preserve (i.e. move to the new commit) the tags.

Regarding your second question, I'm not sure but I think Eike Stepper had a similar comment about tag hierarchies. I just don't know if he has filed a bug for it already ...

Cheers,
Stefan




Am 27.11.11 17:25, schrieb Stephan Herrmann:
Hi,

After massaging the new git repo through branch-filter everything looks
fine inside the IDE, however, when I try to setup the build to use that repo
I'm having two problems with tags:

(1)
most of my tags are not fetched when I do a clone from the cmd line,
instead I get lots of messages like:

error: refs/tags/builds/201111080734 does not point to a valid object!

I guess this has to do with the fact that tags created from SVN tags
are not reachable from any branch (they are actually branching commits
of their own). So, if gc runs not respecting the tags, they'll be collected.
OTOH, EGit seems to know a trick to avoid that, because there all
the tags exists and can be checked out etc.
Any idea where I should look?

Can I tweak the svn-git conversion so that tags are actually part of
their branch, not dead leaves in the tree?

Can I tweak the cloning to actually fetch those tags, too?
If so, can I tell the fetch factory to apply this tweak, too?


(2)
As the error above shows, we have the tradition to nicely structure
tags in folders like build, release, safety, because I don't really like
scrolling through a list of hundrets of builds when I'm looking for
a particular release etc.

I'm not sure to what degree this approach makes sense in Git-land:

EGit still displays a flat list of tags, which just happen to have a '/'
in their names (though on disk I do see a corresponding directory
structure). Is '/' just a part of a name or a path separator?

The current road block, however, is how the git fetch factory handles
these tags: it passes the full name like "builds/201111080734" to
PDE/Build which then uses this name as the version qualifier, so
I'd be building bundles with version "2.1.0.builds/201111080734"
which obviously is an illegal version.

For the SVN fetch factory I had contributed a few tweaks to the
parsing of tag names:
- before passing the tag back to PDE/Build for use as the qualifier
   strip everything until the last '/'
- when tag is specified to "trunk" (here: "master") do not pass to
   PDE/Build any qualifier so they will default to the current date&time
   which is ideal for untagged nightlies.

Does it make sense to make similar changes to the git fetch factory?

thanks,
Stephan




Back to the top