James <[email protected]> writes: > Hello > > On 19 December 2012 08:11, James <[email protected]> wrote: >> Hello, >> >> author Jean-Charles Malahieude <[email protected]> >> Mon, 17 Dec 2012 18:23:13 +0000 (19:23 +0100) >> committer Jean-Charles Malahieude <[email protected]> >> Mon, 17 Dec 2012 18:23:13 +0000 (19:23 +0100) >> commit 12c6693055728e69dce5c4e5a4a2b5f71180a5e2 >> >> Any specific reason this wasn't >> >> 1. Put up for reivew >> 2. Pushed to staging first >> >> This breaks master because, I am guessing as I haven't done much >> analysis, the file name contains commas? >> >> I'm running patchy merge again (just in case it was something >> anomolous - I have time, no problem retesting) but could someone >> revert this or make sure it isn't something else? >> > > Yep this is broken now.
Ok, in case this is still not clear to everybody: NEVER PUSH TO MASTER!!!! Nobody, ever. It messes up our testing and branch organization even when we are not talking about untested changes breaking the compilation. The only one permitted to push directly to master is the lilypond-patchy-staging script since it gives a thorough beating to what it is going to push, making sure that it passes all reasonable tests. In case of manual emergency pushes to master (which should be done by experts only), the state must _first_ be established in staging, _then_ pushed to master. However, pushing from staging to master again is preferably done by lilypond-patchy-staging _after_ appropriately manupulating staging. I'll merge master into staging, revert the problematic commit there, and then the automatisms should be able to take over from there. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
