Re: [git] Tags migrated from SVN

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

Hi Stefan,

thanks for your reply.

I'll try the --tag-name-filter to retain our tags.
(I still wonder how EGit managed to fetch all those half-baked tags).

Regarding the issue of tags in folders/hierarchies I'd really like to hear
if I'm doing something that no git-guru would do/recommend.

Given that neither EGit nor the fetch factory handle this case makes
me feel I'm living in a lonely place.
In that case I might have to swallow the pill and prefer ugly over lonely.
I don't want to create my repo with a layout that is beautiful but not
supported by our tools.

best,
Stephan


On Wednesday, November 30, 2011 05:42:22 PM Stefan Winkler wrote:
> 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
> 
> 
> _______________________________________________
> git mailing list
> git@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/git
>