couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Westreicher Bakk.techn." <>
Subject Re: Committer questions
Date Mon, 20 Jan 2014 08:38:53 GMT
No ff also preserves the knowledge that a branch was merged. I you can see the difference when
running git log --graph. When a fast forward merge is performed it looks like all the merged
commits were done directly on the current branch, merging with no ff shows them on another

Nick North <> wrote:
>Thanks Dirkjan. To clarify the --no-ff merge option: my understanding
>that if this is specified, then git always performs an extra merge
>that makes it clear that a branch has been merged. This applies
>of rebasing the branch on to master. The diagram here
>goes on with and without it. I don't have any view either way myself on
>whether to use it, but it's the sort of thing that seems to provoke
>religious wars so I thought it best to ask.
>On 20 January 2014 07:24, Dirkjan Ochtman <> wrote:
>> On Sun, Jan 19, 2014 at 2:57 PM, Nick North <>
>> > First I'm wondering about when it's OK to push work to the Apache
>> > repository. If you put out a non-controversial GitHub pull request,
>> > there are no negative comments after a reasonable time, is it then
>> to
>> > push it and merge to master, or does it need more positive
>> > I'm hoping it's OK to go ahead, but don't want to raise the wrath
>> group
>> > by pushing code that needs more review.
>> I would say it's definitely okay to go ahead most of the time -- if
>> you spend a lot of time waiting for positive confirmation, the
>> is broken. Obviously it depends on the size and impact of the thing,
>> but we trust you to assess that accurately (and we can always back
>> something out!).
>> > When merging a feature branch to merge to master should you use
>> I think rebasing feature branches onto master is nice, except perhaps
>> in the case of very large feature branches where merging is easier
>> and/or it makes sense to make the conflict resolution from the merge
>> somehwat more explicit. (I'm not quite sure what the --no-ff thing
>> does, still, so I prefer to talk in terms of rebasing versus
>> merging... merging is going on either way).
>> > Are there times when you shouldn't merge to master? At the moment
>the 1.6
>> > release is underway, but I assume that pushing to master is still
>OK, as
>> > there is a separate release branch, so it feels as if it should be
>> to
>> > merge code as soon s it's ready. Or is that too optimistic?
>> If we're close to branching for release, don't push a big fat
>> destabilizing thing. Otherwise, you're okay. :)
>> At least, that's my read on things. Please document consensussy
>> on the wiki!
>> Cheers,
>> Dirkjan

Sent from Kaiten Mail. Please excuse my brevity.

View raw message