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 <[email protected]> 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 <[email protected]> wrote: > >> On Sun, Jan 19, 2014 at 2:57 PM, Nick North <[email protected]> >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.
