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 Mon, 29 Apr 2013 22:06:33 GMT
If production branches follow that rule then there will be broken
commits that won't build. A feature, or fix, will not land atomically,
but in all its constituent parts. That's the thing we are striving to

Do I misunderstand you?


On 29 April 2013 23:00, Benoit Chesneau <> wrote:
> imo production branches should only be rebased, no merge so you keep
> the history easier for people asynchronously branching from
> productions branch. merges can be really difficult to handle along the
> time when you have a branch that differs a lot.
> Also this is why the develop branch exist, so people can merge topic
> branches in it before rebasing  against master.
> - benoit
> On Mon, Apr 29, 2013 at 11:45 PM, Robert Newson <> wrote:
>> I like the idea of +1's to merge from topic to production branch.
>> B.
>> On 29 April 2013 22:23, Dave Cottlehuber <> wrote:
>>> On 25 April 2013 23:57, Randall Leeds <> wrote:
>>>> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <>
>>>>> 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
>>> hope.
>>>> 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?
>>> A+
>>> Dave

View raw message