On Sat, Oct 22, 2011 at 04:41:35PM +0200, David Kastrup wrote: > Dingdingding. I don't think dev/staging should be _merged_, only > fast-forwarded (do the merge using --ff-only). If it is not > forwardable, the dev/staging master should rebase it on master (so that > it becomes fast-forwardable) and submit it to testing (if necessary, by > overwriting dev/staging again).
Hmm. At the moment, master and dev/staging cannot be "combined" (to use hopefully non-specific terminology) with --ff-only. Bertrand's 6ee8c04678442855cb794d4598c056c15c42673b gets in the way of doing git merge --ff-only in either way. My initial instinct would be just to do git checkout master git merge dev/staging ..test... git push but I'm going to hold off until you advise me on this. > The problem is that a merge means > a) the particular version to be committed has not been tested. I don't think this is terribly important. I mean, yes it's theoretically true that 6ee8c04678442855cb794d4598c056c15c42673b could have ruined your patches in dev/staging, but as long as the combination can compile, we haven't *lost* any reliability relative to the status quo. > b) if one patch in the series is bad, the whole merge needs to be > reverted. Reverting a merge is _really_ _really_ bad. After that, > all changes are gone, but git is of the opinion that it has > considered all source patches already. Cherry-picking any of them > won't help. The only remedy is reverting the revert, and then > reverting single patches. Ouch ouch ouch. This sounds more serious. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
