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 _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
