On Mon, Apr 29, 2013 at 6:59 AM, Robert Newson <[email protected]> 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 <[email protected]> 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?
