Graham Percival <gra...@percival-music.ca> writes: > 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.
I'd do something like git fetch git rebase origin/master origin/dev/staging [Note that you are now outside of any branch] ..test... git push origin HEAD:master git reset --hard master or git rebase origin master And you are back to your own master... >> 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. It is a bloody nuisance. I did that once in Lilypond development and despaired getting my changes (even the unmodified whole merge commit) back into the tree. It did not help that kernel.org with its Howtos was down. Basically, don't revert a merge commit if you want to see any commit of it ever again. If you do, you have to revert the revert itself, getting back to square 1 first before you can tackle the reason for the revert in a way different from reverting the whole merge. Or do other tricks convincing git that the effect of the revert should not prevail. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
