Re: Extra merge commits in gnome-doc-utils

[Owen Taylor <otaylor redhat com>]

On Tue, 2009-09-08 at 09:35 -0500, Shaun McCance wrote:

> > 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.

It's not obvious that:

 git push # pushes master
 git push --tags # just pushes tags and not master

and that you have to:

 git push origin master --tags

To push both.

> 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.

You can simple 'git commit --amend' your merge commit and give
it a better subject. The merge commit check is intentionally
a dumb check on whether the subject matches:

 ^.*Merge branch.*of.*(git|ssh):

You couldn't do this for your situation since you had such
commits as ancestors of the tag, but if it's just a single
commit merging things back together to push to master, then
it's easy.

- Owen