David Kastrup <d...@gnu.org> writes: > David Kastrup <d...@gnu.org> writes: > >> David Kastrup <d...@gnu.org> writes: >> >>> Please _don't_ ever push a "fix" on top of a broken staging branch. We >>> want to keep master compiling always. If your fix works, it means that >>> Patchy will move both the broken commit as well as the fix to master. >>> >>> I've cleared both for now and hope that no Patchy has already picked the >>> "fix" up. I'll investigate what to do here. >>> >>> It is not quite clear to me how the bug went through my tests, and why >>> Patchy does not complain (apparently make doc does not compile the "new" >>> snippets ?!?). >>> >>> So we already have one fishy commit in master, but at least it is "make >>> doc" clean. >> >> Pushed a fix to staging on top of master and cleared out your changes >> (after moving them to a private branch so that they don't get lost). >> Let's see what commit Patchy moves to master next, and go from there. > > John, could you _please_ stop "fixing" things in staging? You now > merged master into the diverged staging. This is getting a larger and > larger mess. I am undoing this and hope that at least _this_ will not > get caught by Patchy again.
The whole purpose of staging is that changes that should not get into master get _caught_ before they move into master (which is permanent). If you put "fixes" on _top_ of something bad in staging, the whole mess _will_ move into master the next time Patchy catches up. So _please_ _please_ _please_ _don't_ "fix" staging if you don't know _exactly_ what you are doing. If Patchy is deadlocked, it is deadlocked in order to stop things moving into master. The proper cure then is to _remove_ staging and replace it by a version where the mistake has never been made. _Not_ fudge around until a bunch of bad history is ready to move from staging into master. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
