Re: [git] Tags migrated from SVN

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

Hi,

in case s.o. else also wants to try the --tag-name-filter trick:
==> in my case the result was: zero.

Before and after using this trick the git command line clone would complain:
    error: refs/tags/builds/201005062059 does not point to a valid object!
while EGit is always able to fetch the tag and work with it.

However, I can restore tags by manually re-tagging in EGit using a new
name and pushing this tag to the repo.
After that the invalid object pointed to by the original tag all the
sudden becomes valid. Command line git can now pull the new tag into 
the non-EGit clone *and* also the old tag pointing to the same commit
becomes usable by this operation.

Obviously, this solution makes sense only for resurrecting a small
number of tags ...

weird,
Stephan


On Tuesday, December 06, 2011 04:55:45 PM Stephan Herrmann wrote:
> 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
> > 
> _______________________________________________
> git mailing list
> git@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/git
>