Quite in phase of what I proposed 6 months ago: http://markmail.org/thread/ec3okssflzbms4pw
- benoit On Mon, Apr 29, 2013 at 3:48 PM, Noah Slater <nsla...@apache.org> 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 <rnew...@apache.org> 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 <rnew...@apache.org> 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 <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. >> > > > > -- > NS
