Hello Eric, Gary, * Gary V. Vaughan wrote on Wed, Apr 16, 2008 at 11:51:48PM CEST: > On 16 Apr 2008, at 16:47, Eric Blake wrote: >> there are now some stale tags >> in savannah's libtool.git, which point to commits prior to your >> various git- >> filter operations (for example, the tag release-2-2-2 >> http://git.sv.gnu.org/gitweb/?p=libtool.git;a=tag;h=c7bb42 >> points to http://git.sv.gnu.org/gitweb/? >> p=libtool.git;a=commit;h=2bbe5d >> rather than >> http://git.sv.gnu.org/gitweb/?p=libtool.git;a=commit;h=724f291). >> Are you planning on rewinding those tags to point to something more >> appropriate? And if so, please post the new SHA1 of the tags.
Yes, I think I should do so. How can I do it? And what's more, what did I forget to do so that this could happen? > Either I'm misunderstanding you, or you're looking in the wrong place > (an old libtool.git; stale browser cache?). Please try again, Gary. 724f29122c655bdbda845af92a3ca0cf36aaa67d is the tree that designates 2.2.2. >> Gary, since you released 2.2.2, would you mind matching the convention >> of other savannah git projects and do: >> >> $ git tag -s -m 2.2.2 v2.2.2 724f2912 >> $ git push origin refs/tags/v2.2.2 > > I'd be happy to run: > > $ git tag -s -m 2.2.2 v2.2.2 2bbe5d > $ git push origin refs/tags/v2.2.2 > > If you agree that is the right thing to do? No, that's not right. >> That way, gnulib's git-version-gen script will produce a meaningful >> output on libtool (even though we are not presently using >> git-version-gen in the libtool bootstrap). I'd do it, but then the >> gnupg signature would be mine instead of yours. > > Playing devil's advocate: Whether 'git describe' produces meaningful output is independent of whether we should use git-version-gen. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
