couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: [DISCUSS] Git workflow
Date Mon, 29 Apr 2013 21:23:37 GMT
On 25 April 2013 23: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.

Possibly from people just getting to grips with dvcs like git. A
couple of years ago I definitely struggled with understanding
bisecting with merged branches but I would have less trouble now I

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

If it's more than a single commit, then yes this makes sense to me
too, I wasn't aware there was flag for it.

Re integration branches, it does not strike me as necessary if we can
collectively ensure we test branches when people are ready to merge
them. eg my recent screw-up. caveat coder :-(

So perhaps we should get  a +1 from say a couple of reviewers when you
want to merge something into a production branch. I like the openbsd
commit messages in this respect, although we could do that in jira
rather than in the commit. Reasonable?


View raw message