On Wed, May 22, 2013 at 3:29 AM, Randall Leeds <[email protected]> wrote: > On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <[email protected]> > wrote: >> Here's a diagram. In this I show a feature branch landing on master >> and a backport of it landing on 1.3.x, but if we follow the procedure >> I'm suggesting I think it can even be easy to keep track of >> cherry-picked backports. >> >> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY >> >> The fancy things here are >> * merge-base: to find the common ancestor
As in, the common ancestor on a release branch? Because you don't want to use the old feature branch head as ancestor, but rather the branch point where the release branch deviated from master? >> * --no-commit: so NEWS and CHANGES can be reconciled atomically with >> respect to what the git logs will say is unmerged Not sure why you'd need that here. >> * -Xours: so that we can merge release branches to master *without* >> code changes, just to mark a point in history so that a future >> merge-base will only show us what hasn't made it into NEWS and CHANGES >> since we last did this. > > (snip) > > But maybe I'm overthinking it since one alternative is to just update > NEWS and CHANGES whenever we make commits. However, I think if we just > merge releases to master whenever we make a backport or a release then > it will be a very quick and painless process to update NEWS and > CHANGES when it comes time for 1.4.x. Yeah, I don't think we actually need the "ours" merge strategy here. I do think we should try merging from release branch to master some time soon (e.g. after the next feature release). Cheers, Dirkjan
