lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patchy email


From: David Kastrup
Subject: Re: Patchy email
Date: Fri, 26 Jul 2019 20:36:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

James <address@hidden> writes:

> Hello,
>
> On 26/07/2019 16:13, David Kastrup wrote:
>> David Kastrup <address@hidden> writes:
>>
>>> David Kastrup <address@hidden> writes:
>>>
>>>> fatal: Not a valid object name master
>>>>
>>>> Apparently, the patch from
>>>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>>>> Author: Knut Petersen <address@hidden>
>>>> Date:   Sun Jul 7 13:16:05 2019 +0200
>>>>
>>>>      Optimize tree.gittxt messages
>>>>           We display BRANCH, HEAD, MERGE-POINT
>>>>      and HISTORY fom merge-point to HEAD.
>>>>           If we do not find a merge-point we
>>>>      display the last ten commits if this
>>>>      is possible.
>>>>
>>>> relies on the existence of a local (rather than upstream) branch
>>>> "master", not a good idea.  I am backing out this commit from staging:
>>>> it needs to get fixed.
>>> Someone or some patchy happening to have a local master branch (a bad
>>> idea since absolutely no development should happen in a local master
>>> branch in our setup) already pushed that commit to staging.
>> I mean, to master.  Pushing to staging was very much the correct step to
>> take in the life of the patch.
>>
>>> Consequentially, I had to push a revert to staging and hope I'll get it
>>> through without manually tampering with master.
>
> I personally closed the sourceforge ticket with the commit ID etc.
>
> --snip--
>
> pkx166h <https://sourceforge.net/u/lilypond-pkx/> - /3 days ago /
> <https://sourceforge.net/p/testlilyissues/issues/5534/#d5a7>
>
> Optimize tree.gittxt messages master staging
> author  Knut Petersen <address@hidden>
>     Sun, 7 Jul 2019 12:16:05 +0100 (13:16 +0200)
> committer   Knut Petersen <address@hidden>
>     Mon, 22 Jul 2019 10:04:40 +0100 (11:04 +0200)
> commit  7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>
> --snip--
>
> However looking at the date stamps of the logs of my patchy runs - the
> patchy scrits generate text files for each run - I ran one on the 25th
> (pushing Urs trivial checkin) and then before that on the 17th, which
> was for Knut's previous fix (and I think included Werner's).
>
> So there is another patchy pushing stuff as Knut's 'failed' commit was
> in between those times.

I run Patchy when I notice something went to staging.  Due to its cost,
I tend to abort it when I discover someone else pushing before me.

So it would appear that your repository (and probably that of Knut) have
a local master branch which would mask that the patch in question does
not produce output relative to the origin repository and thus produces
stuff that is not reducible.  A local master branch tends to be a bad
idea (though not as bad as a local staging branch) since you don't want
to collect changes of your own on it.

> Unless Knut is also running patchy now that he has commit access (and
> perhaps didn't have a clean master?).
>
> (I don't want to cast aspersions, but it might be a genuine mistake if
> it was Knut). Knut?

I rather doubt that it was Knut since I mentioned the procedures to him
right now and you said that you pushed the patch in question anyway (so
it's very unlikely that he'd run the patchy subsequently responsible for
promoting it to master).

The more likely version is that your repository, having a local master
branch, failed figuring out that the patch was problematic and promoted
it to master.  And my patchy version, running at some later date to push
an unrelated patch, got tripped up by the change that had entered master
because of your Patchy not tripping over the behavior that my Patchy got
stuck on.

And my first mails were based on me missing that the problematic patch
in master had already been there for a day or two.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]