cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul cannon <>
Subject Re: Cassandra has moved to Git
Date Wed, 04 Jan 2012 17:30:58 GMT
On Wed, Jan 4, 2012 at 10:57 AM, Eric Evans <> wrote:

> On Wed, Jan 4, 2012 at 9:59 AM, Jonathan Ellis <> wrote:
> > On Tue, Jan 3, 2012 at 1:21 PM, paul cannon <> 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

> 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. :)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message