Re: [Lilypond-auto] Patchy email

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> David Kastrup <address@hidden> 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