If production branches follow that rule then there will be broken commits that won't build. A feature, or fix, will not land atomically, but in all its constituent parts. That's the thing we are striving to avoid.
Do I misunderstand you? B. On 29 April 2013 23:00, Benoit Chesneau <bchesn...@gmail.com> wrote: > imo production branches should only be rebased, no merge so you keep > the history easier for people asynchronously branching from > productions branch. merges can be really difficult to handle along the > time when you have a branch that differs a lot. > > Also this is why the develop branch exist, so people can merge topic > branches in it before rebasing against master. > > - benoit > > On Mon, Apr 29, 2013 at 11:45 PM, Robert Newson <rnew...@apache.org> wrote: >> I like the idea of +1's to merge from topic to production branch. >> >> B. >> >> On 29 April 2013 22:23, Dave Cottlehuber <d...@jsonified.com> wrote: >>> On 25 April 2013 23: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. >>> >>> 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
