openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

On Fri, 2012-05-11 at 17:22 -0700, Vishvananda Ishaya wrote:
> On May 11, 2012, at 2:04 PM, Mark McLoughlin wrote:
> > 
> > I'm guessing we could easily flick a switch in gerrit to cause it to
> > rebase instead of merge.
> > 
> > I don't remember any debate about it, but I'm also guessing there aren't
> > any hugely strong opinions in OpenStack about which is better.
> > 
> > The thing we'd lose is the context of which parent commit a patch was
> > written against. If I was to go by some of Linus's rants I'd think this
> > was a cardinal sin ("NEVER destroy other people's history") yet kernel
> > folks do this all the time by emailing around patches.
> > 
> > On balance, I think I'd prefer if we did switch over to rebasing.
> 
> I would prefer a rebase as well, the merge commits make it hard to
> figure out via grep exactly where a fix/feature hit master.

This:

  $> git log --no-merges --topo-order

gives you the commits in the order they were merged, but without the
merge commits.

The fact that you can hide the ugliness with clever flags to git-log
doesn't mean the history isn't ugly, though :-)

> I actually suggested this on irc the other day. There was some concern
> that it would cause more merges to be rejected because they don't
> rebase cleanly, although It is a little tough for me to come up with a
> situation where a merge commit applies cleanly but a rebase fails.

Yeah, I've a suspicion that rebase can fail where merge would succeed,
but I'm not sure why I think that - they should be identical three way
merges, right?

Cheers,
Mark.