James <pkx1...@runbox.com> writes:
> On 26/07/2019 19:36, David Kastrup wrote:
>> ...
>> 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.
>
> However the patchy scripts set up a local master
>
> e.g. If I manually delete my local master and then run the patchy scripts:
>
>> Branch 'master' set up to track remote branch 'master' from 'origin'.
>> Switched to a new branch 'master'
>
> (or is that not what you are talking about?)
It is, but that does not happen in my repository when running
lilypond-patchy-staging.py . Since there is no point in maintaining a
local master potentially differing from upstream in the testing scripts,
I wonder what script would be responsible here.
> My workflow is that I always make sure that dev/local_working (where I
> do my own changes before creating patches), local staging and local
> master are always 'in sync' before I run patchy and that staging is
> cleaned.
>
> It's no different than what I have always done.
>
> So I wonder why the tests passed and my own patchy merge passed but
> yours failed?
My patchy-staging test does not create a local master and I don't
maintain one of my own. I wonder why it would be different from yours.
> I am just worried that the veracity of my patch testing is not good
> enough
My lilypond-extra is up to date with two patches on top (that likely
should at some time be pushed):
commit c8c317eed3e774fb73132e48071ebd14bdda1b88 (HEAD -> master)
Author: David Kastrup <d...@gnu.org>
Date: Tue May 19 10:21:13 2015 +0200
Replace --disable-optimising with the faster --enable-checking
commit 6d784e9a2c5e7f0f1baf6cd500459504be51826e
Author: David Kastrup <d...@gnu.org>
Date: Tue Feb 12 11:11:57 2013 +0100
Use printf rather than echo for result script to avoid interpreted
backslashes
Neither of those would make a difference in that regard.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
