couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [DISCUSS] Git workflow
Date Mon, 29 Apr 2013 19:01:21 GMT
On Mon, Apr 29, 2013 at 6:59 AM, Robert Newson <rnewson@apache.org> wrote:
> 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.

-0 on single commit branches being merged with --no-ff. I think you're
right: there's no reason to turn 1 commit into 2 just to have the
merge commit in the log. In that case, the single commit serves as its
own merge.

It's probably still better to merge it rather than cherry-pick if it's
been sitting in a branch while master moved ahead. There's tooling
around visualizing which branches are merged or not (e.g., git branch
--merged). Github makes this apparent in their branch UI. This is
helpful for cleaning up old branches.

Do we still need to decide on develop/master/1.X.Y stuff? Will we have
a develop branch or just master?

Mime
View raw message