On Wed, Jan 4, 2012 at 9:59 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > On Tue, Jan 3, 2012 at 1:21 PM, paul cannon <p...@datastax.com> wrote: >> Surely we'd want to follow normal git practices here: rebasing is almost >> never appropriate once a branch is pushed to a public repo, where other >> people might have gotten it. >> >> Where you might rebase a plain patch series on top of new developments in a >> target SVN branch, you probably just ought to merge the target git branch >> into your topic branch instead. Same effect, but retains history. > > I dunno, my experience has been that merge commits cause more harm in > my ability to understand history, than I gain in benefit. Merge > commits mean another place to look to understand "what really changed > in this patch."
I'm not following. What other place do you mean? This is one of the problems I had with Subversion since a merge commit was one giant changeset that represented a bunch of individual changes from another branch. Understanding what had really changed meant finding finding what had changed between that merge and the previous one (though maybe there was an easier way; my Subversion-fu always felt inadequate). In Git, the merge commit is basically metadata, and the commits merged in are preserved in their entirety. Git log tells the whole story doesn't it? > http://darwinweb.net/articles/the-case-for-git-rebase makes a good > case for a rebase-based workflow, particularly with respect to > bisecting (which has been instrumental in tracking down regressions > for us more than once). I don't understand several of his arguments. How bisecting is made more difficult (or impossible) is one of them. I also don't understand how rebasing to master versus merging with master is superior in terms of avoiding larger conflicts down the road (especially since the example he provided didn't indicate any merges with master(!)). Personally, I do prefer to rebase my branches while they are private, but that's for purposes of easing review; I've never felt I needed a flatter history to make life easier (with Git). Anyway, if I understand what he's saying, he's suggesting that individual developers rebase against master to stay current, only up until the first time they push it somewhere. Then presumably two or more developers merge back and forth between each others topic branches. Once the work is complete, someone rebases to master and merges, at which point that topic branch is considered to be dead. In a perfect word (his private team?) that should work, and if consensus is that we should try it, then I'm down. My prediction: Bedlam. :) -- Eric Evans Acunu | http://www.acunu.com | @acunu
