"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 <randall.le...@gmail.com> wrote: > On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <rnew...@apache.org> 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.
