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
