Hello,
On 27/07/2019 10:10, David Kastrup wrote:
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.
I don't think it is any script per se, I used to use Lily-git (which
fetches master and staging and sets up dev/local_working.
So I've always had a local master.
Also, I test patches against current master (not staging) so I'd need a
local master then too right?
i.e
checkout master, run make, make test-basline, apply patch etc etc.
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 don't run a script to test patches - the script 'broke' when we moved
from Google to Sourceforge, so I just test patches 'manually' (out of
tree) but I do make sure my local master is reset 'hard' (so to speak)
before I test things.
Patchy-merge scripts are the ones I have always used
and it creates a 'lock' branch test-master-lock (I think as a kind of
simple failsafe if a user ends up running two or more instances or a
previous instance failed to complete or clean up properly).
I use the script from lilypond-extra/patches/(compile_lilypond_test).
James
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
