Re: Extra merge commits in gnome-doc-utils

[Shaun McCance <shaunm gnome org>]

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