couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Mon, 29 Apr 2013 21:45:18 GMT
I like the idea of +1's to merge from topic to production branch.

B.

On 29 April 2013 22:23, Dave Cottlehuber <dch@jsonified.com> wrote:
> On 25 April 2013 23:57, Randall Leeds <randall.leeds@gmail.com> wrote:
>> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <rnewson@apache.org> 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
> 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

Mime
View raw message