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.
pgp5cT2VLf45M.pgp
Description: PGP signature
