Re: Extra merge commits in gnome-doc-utils
- From: Owen Taylor <otaylor redhat com>
- To: Shaun McCance <shaunm gnome org>
- Cc: gnome-infrastructure gnome org
- Subject: Re: Extra merge commits in gnome-doc-utils
- Date: Tue, 08 Sep 2009 12:27:07 -0400
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:
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
] [Thread Prev