couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 21:59:50 GMT
"I'm not sure where this notion that bisecting with merge
commits is harder comes from."

>From personal experience, but I concede this might point to my
deficiency and not git's.

On 25 April 2013 22:57, Randall Leeds <> wrote:
> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <> wrote:
>> If we enhance the #1 proposal to include a final rebase against master
>> before merge, then master will be truly linear. That will make for
>> easier reading, easier backporting and will enable bisecting when
>> spelunking for regressions, etc.
> I disagree.
> git-bisect is smart enough to remove whole merges before diving into
> their constituent commits, IIRC, which reduces the possibility of
> false negatives if there were intermediate commits that had failing
> tests on the feature branch but the ultimate merge was clean and
> green. I'm not sure where this notion that bisecting with merge
> commits is harder comes from.
> Similarly, backporting a topic branch should look something like:
>> git checkout -b topic-branch-1.3.x-backport topic-branch
>> git rebase --onto 1.3.x master
> This would produce a branch (topic-branch-1.3.x-backport) which
> contains all the commits on topic-branch since it diverged from
> master, rebased onto 1.3.x.
> Reading history with merge commits can also be easier than the
> alternative FF-only history since there is a --merges option to
> git-log. This feature can, for instance, show you time line of topic
> introduction without the clutter of the individual commits that were
> necessary to produce them.
> If I am going to argue one way or another I would actually suggest
> that feature or topic branches always merge with --no-ff.

View raw message