On Tue, 2009-09-08 at 09:59 -0400, Owen Taylor wrote: > On Mon, 2009-09-07 at 21:25 -0500, Shaun McCance wrote: > > So gnome-doc-utils has gotten itself a fairly wonky history > > due to mistakes on my part. What happened is that I made > > releases, tagged the release commits, and pushed the tags, > > but I didn't push master. So the commits got pushed, but > > origin/master wasn't updated. > > > > If you look at the history for gnome-doc-utils in giggle, > > you can see the problem pretty clearly. > > > > I want origin/master to point to 0.17.5, or to something > > that includes 0.17.5 in its history, but this doesn't seem > > possible with our extra merge commits check. If I rebase > > 0.17.5 on top of origin/master, I get bogus extra release > > commits, but the signed release commits still aren't in > > the history of origin/master. It's ugly. > > > > Since those commits are pushed and tagged, there's no way > > history can be fixed now. The cleanest thing to do would > > be to just make origin/master point to 0.17.5, but I can't > > make this happen. Could a git admin make it so? > > Done, using > > git push --exec=force <commit_id>:master > > (--exec=force is gitadmin only, though I wonder if some types > of less dangerous check-bypasses should be forceable by > everbody.)
Thanks Owen. > Filed: > > http://bugzilla.gnome.org/show_bug.cgi?id=594498 > > That we should try to catch your original problem and not allow > pushing tags that don't point to some branch. Indeed it would. I don't know why it didn't occur to me that I wasn't actually updating master on the server. Although this makes me think of a more legitimate scenario where I think you'd run into the extra merge commits check. What if I make a release, and while I'm doing so, somebody else pushes a commit? * Some translation update | * My release |/ * Old origin/master You certainly don't want to rebase a release commit without amending the NEWS entry in that commit and re-rolling the tarball. In the old CVS/SVN days, we told people that if this happened, they'd have to re-roll. But re-rolling tarballs is a serious pain, and it seems silly to require it when our version control system is no longer too dumb to handle the situation. -- Shaun _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
