I like the idea of +1's to merge from topic to production branch. B.
On 29 April 2013 22:23, Dave Cottlehuber <[email protected]> wrote: > On 25 April 2013 23: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. > > Possibly from people just getting to grips with dvcs like git. A > couple of years ago I definitely struggled with understanding > bisecting with merged branches but I would have less trouble now I > hope. > >> 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. > > If it's more than a single commit, then yes this makes sense to me > too, I wasn't aware there was flag for it. > > Re integration branches, it does not strike me as necessary if we can > collectively ensure we test branches when people are ready to merge > them. eg my recent screw-up. caveat coder :-( > > So perhaps we should get a +1 from say a couple of reviewers when you > want to merge something into a production branch. I like the openbsd > commit messages in this respect, although we could do that in jira > rather than in the commit. Reasonable? > > A+ > Dave
