Can we move the rest of this discussion over to the "[DISCUSS] Git workflow" please. :)
The focus of this thread is: what do we need to do to make sure we can call a successful vote on Thursday? On 22 May 2013 17:38, Dirkjan Ochtman <[email protected]> wrote: > 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 > -- NS
