Alls well that ends well On Nov 1, 2013, at 11:41 PM, Jed Brown <[email protected]> wrote:
> Satish Balay <[email protected]> writes: > >> On Fri, 1 Nov 2013, Barry Smith wrote: >> >>> Like how are we going to do that? Every time someone merges to >>> next I check it and decide if that branch also needs to be merged >>> into all my long living branches. Yeah like that is going to >>> happen. >> >> I don't think you are supporsed to do that unless you specifically need >> the features from this branch. And then you keep track of future >> fixes - and see if you need to remerge. > > Alternatively, when someone makes a bug-fix in a branch that has been > "released" (merged to 'next' or someone else's branch), they run > > git branch -r --contains THE-BAD-COMMIT > > and pings the relevant people (maybe just tag them in a bitbucket > comment on the commit). > >>> The reason I had to merge all that stuff into saws was that saws could >>> not merge into next because those branches so changed next. I had to merge >>> them into saws before I could get saws into next. But I missed 1/2 a one >>> (somehow) getting an outdated verson of the sf-sfbasics into saws. >>> >> >> No the more appropriate thing here would be to merge/rebase to latest >> master. >> >> And then attempt to merge saws to next. > > Too late for that now and I don't have a problem with the version that > merges, but it should make sure that anything being merged in is in a > "releasable" state.
