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 13:59:14 GMT
Bah, I meant:  I'm +0 on single commits merging from topic to master withOUT
a merge commit.

On 29 April 2013 14:58, Robert Newson <rnewson@apache.org> wrote:
> Ok, my proposal is #1 from my original post with the refinement from
> Randall which I think we can distill as "you must not flatten a commit
> set". If your topic branch is best represented as >1 commit, then it
> must land on master as a merge commit. The other way to say it is that
> no topic branch is partially merged; it must be atomic. This means
> that branches, typically bug fix branches, which are naturally a
> single commit will simply fast forward. I'll let Randall respond to
> that point. I'm +0 on single commits merging from topic to master with
> a merge commit.
>
> B.
>
> On 29 April 2013 14:48, Noah Slater <nslater@apache.org> wrote:
>> Does anybody have any other thoughts on this? We need to choose something
>> as soon as possible.
>>
>>
>> On 25 April 2013 23:01, Robert Newson <rnewson@apache.org> wrote:
>>
>>> Another point in favour of merge commits (non-ff) is that the branch
>>> merged to leaps forward atomically. It might not be appropriate to see
>>> the intermediate tree for a feature that consists of multiple commits.
>>>
>>> B.
>>>
>>> On 25 April 2013 22:59, Robert Newson <rnewson@apache.org> wrote:
>>> > "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 <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.
>>> >>
>>> >> 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.
>>>
>>
>>
>>
>> --
>> NS

Mime
View raw message