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. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp