On Wed, Jan 4, 2012 at 10:57 AM, Eric Evans <eev...@acunu.com> wrote:
> 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 agree with Eric- merges shouldn't be making history searches any more difficult. > 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). > I only read through that article quickly, but it doesn't sound like he ever even addresses public repos, where rebasing remote heads and pushing non-fast-forward updates causes pretty massive confusion for people who aren't pretty familiar with git. Perhaps he's just advocating rebasing locally? I am 100% in favor of that, and it sounds like Eric is too- rebase is almost always preferable to merge as long as you're not messing up any remote heads. Although I disagree with the last bit: flatter histories do make life easier in general. 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. :) > This. p
