On Fri, Aug 8, 2014 at 12:27 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi Daan, > > On 08-Aug-2014, at 12:05 pm, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > >> Rohit, >> >> A remark and a question: ... >> Why insist on fast-forward? (In the git-flow document it is emphasised >> that --no-ff should be used at all times) > > So, in my proposal I ask developers to merge release (or stable) branches to > master (or develop/feature branch) often (say couple of times in the day), > using --no-ff will generate a merge commit every time we do that. With > fast-forward we’ll get linear history so that’s why I keep insisting on it. > > IMO We should only use --no-ff only when we want to have git to track the > merge history (i.e. for someone to go and see what feature/branch got merged > and what work was done in that merge branch).
Right, I just committed two fixes that are now just commits on 4.4 and would have shown with merge commits, proving I eat my own dogfood. I must say I am really not sure what I prefer. Leo showed me another example of the difference where a merge was done on a branch that had grown since the branch-off. Let's define carefully what we need when. Not everybody is going to be savvy on this within the community and a clear "do this, don't do that" might save the day. A linear history is maybe good for little fixes/hotfixes but for bigger features you do want the merge commit so you see clearly the sideway that was created during the implementation. ok?
