Erm, sorry, Tuesday. :) (And to clarify, I'm pumped we're having this conversation, I just wanna separate the threads!)
On 22 May 2013 17:55, Noah Slater <[email protected]> wrote: > 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 > -- NS
