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. > > B. > > On 29 April 2013 14:48, Noah Slater <[email protected]> wrote: >> Does anybody have any other thoughts on this? We need to choose something >> as soon as possible. >> >> >> On 25 April 2013 23:01, Robert Newson <[email protected]> wrote: >> >>> Another point in favour of merge commits (non-ff) is that the branch >>> merged to leaps forward atomically. It might not be appropriate to see >>> the intermediate tree for a feature that consists of multiple commits. >>> >>> B. >>> >>> On 25 April 2013 22:59, Robert Newson <[email protected]> wrote: >>> > "I'm not sure where this notion that bisecting with merge >>> > commits is harder comes from." >>> > >>> > From personal experience, but I concede this might point to my >>> > deficiency and not git's. >>> > >>> > On 25 April 2013 22:57, Randall Leeds <[email protected]> wrote: >>> >> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <[email protected]> >>> wrote: >>> >>> >>> >>> If we enhance the #1 proposal to include a final rebase against master >>> >>> before merge, then master will be truly linear. That will make for >>> >>> easier reading, easier backporting and will enable bisecting when >>> >>> spelunking for regressions, etc. >>> >> >>> >> I disagree. >>> >> >>> >> git-bisect is smart enough to remove whole merges before diving into >>> >> their constituent commits, IIRC, which reduces the possibility of >>> >> false negatives if there were intermediate commits that had failing >>> >> tests on the feature branch but the ultimate merge was clean and >>> >> green. I'm not sure where this notion that bisecting with merge >>> >> commits is harder comes from. >>> >> >>> >> Similarly, backporting a topic branch should look something like: >>> >> >>> >>> git checkout -b topic-branch-1.3.x-backport topic-branch >>> >>> git rebase --onto 1.3.x master >>> >> >>> >> This would produce a branch (topic-branch-1.3.x-backport) which >>> >> contains all the commits on topic-branch since it diverged from >>> >> master, rebased onto 1.3.x. >>> >> >>> >> Reading history with merge commits can also be easier than the >>> >> alternative FF-only history since there is a --merges option to >>> >> git-log. This feature can, for instance, show you time line of topic >>> >> introduction without the clutter of the individual commits that were >>> >> necessary to produce them. >>> >> >>> >> If I am going to argue one way or another I would actually suggest >>> >> that feature or topic branches always merge with --no-ff. >>> >> >> >> >> -- >> NS
