couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Westreicher Bakk.techn." <st...@meredrica.org>
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
branch. 

Nick North <north.n@gmail.com> wrote:
>Thanks Dirkjan. To clarify the --no-ff merge option: my understanding
>is
>that if this is specified, then git always performs an extra merge
>commit
>that makes it clear that a branch has been merged. This applies
>regardless
>of rebasing the branch on to master. The diagram here
><http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html>shows
>what
>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.
>
>Nick
>
>
>On 20 January 2014 07:24, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
>
>> On Sun, Jan 19, 2014 at 2:57 PM, Nick North <north.n@gmail.com>
>wrote:
>> > 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,
>and
>> > there are no negative comments after a reasonable time, is it then
>fine
>> to
>> > push it and merge to master, or does it need more positive
>confirmation?
>> > I'm hoping it's OK to go ahead, but don't want to raise the wrath
>of
>> 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
>process
>> 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
>--no-ff?
>>
>> 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
>fine
>> 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
>possibly
>> destabilizing thing. Otherwise, you're okay. :)
>>
>> At least, that's my read on things. Please document consensussy
>things
>> on the wiki!
>>
>> Cheers,
>>
>> Dirkjan
>>

-- 
Sent from Kaiten Mail. Please excuse my brevity.

Mime
View raw message