On Tue, Nov 29, 2011 at 03:41:25AM +0100, David Kastrup wrote: > Graham Percival <[email protected]> writes: > > > 2) remove that commit, then rebase origin/staging on the result. > > > > I'm not comfortable rewriting history on a shared repository. > > I'll do the second one. Rewriting history is easy, and that is what > staging is for.
Excellent! > The aftermath will be more interesting. People > committing to staging (and rebasing on staging) should double-check that > they are only committing their own commits and not old commits we chose > to back out. ... yes, "interesting times ahead" indeed. > An interesting question is how the commit could > a) acquire changes not at all described in the commit message eh? The description seems legit here. At least, I assume that changing \super to \normal-size-super would "enlarge half-diminished slash circle symbol". > b) pass testing and acquire "Push" status 1503 had a whole bunch of changes, and it was waiting for something like 3 weeks before getting pushed. It's possible that that syntax worked before the recent scheme changes, or it's possible that James wasn't testing on a completely clean build tree and lilypond doesn't regenerate that part of the docs... come to think of it, since the change was in a ly/ file rather than input/, I very much doubt that the build system would notice that dependency changing. *shrug* I see no reason to panic about this. Unless we vastly ramp up the amount of red tape, there will always be some patches that slip through the cracks. I think the best option is to improve the automation; if I can reliably leave my computer compiling stuff 24 hour a day, then there's no problem recompiling absolutely everything from scratch all the time. Cheers, - Graham _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
