Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAPaJBx542ckNORQmCZy4jrvi6yU+oZT7VupQ9v6-Z+3a1nPyGQ@mail.gmail.com>
References: 
 <CABvT1DEWv4LA6mXp=+58t5yUEFVREQ7TEvQkoPsKg09bnH8PtA@mail.gmail.com>
	<CAPaJBx7phxVb5Ec+vbEytUXe88aUkAyxbbV0WnUOuBav_41SVQ@mail.gmail.com>
	<CAD2UGCXzjDt7FsxFbhQiL_YWiTCOowdFS7GKqW=Ffzbt6bzR_Q@mail.gmail.com>
	<CAPaJBx41=vxO808mtPPw3BuVYBiKuBZhig_iOHb75Ov5isgr0w@mail.gmail.com>
	<CABvT1DG27VhdUyxqXeo6=eKVEzEOvZmUTgTHA1PMrT-=+kBm2A@mail.gmail.com>
	<CAAL6JQgng76tWWqM7NmZSbzyA2b84hRa6AnV-X_HFkiPdkLVfw@mail.gmail.com>
	<CABvT1DHqkRJ=xKPhnvKTugLLBQaoP00FWev5jemY6-dMHuhPRg@mail.gmail.com>
	<CABvT1DEveG3k0jt7UhZ8DL61M9KFNipUOpq0LH=2XQgKROt3Sg@mail.gmail.com>
	<CAPaJBx542ckNORQmCZy4jrvi6yU+oZT7VupQ9v6-Z+3a1nPyGQ@mail.gmail.com>
Date: Mon, 29 Apr 2013 14:58:51 +0100
Message-ID: 
 <CABvT1DFxcOEpm0kjxbS3e-_-_Oks=pDn3XbJK2P0_a9AWHtcXw@mail.gmail.com>
Subject: Re: [DISCUSS] Git workflow
From: Robert Newson <rnewson@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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