Re: staging patchy problem.

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Sun, Feb 05, 2012 at 10:43:49AM +0100, David Kastrup wrote:
>> for some reason unfathomable to me, the staging patchy contains the
>> following code in compile_lilypond_test.py:
>
> The intent is that after doing staging->master, patchy's master
> should be updated so that a later run of test-patches.py doesn't
> miss any updates.

If test-patches.py needs a particular state of master/index, it should
cater for it by itself rather than rely on the state left by some
independent tool running asynchronously.

> For example, if somebody is pushing a whole bunch of syntax changes,
> you definitely need the material in patchset 1 before trying to test
> patchset 2.

What has that to do with staging-patchy?

> I make no claim that this is the proper way to do it in git.
>
>> This is a _total_ nuisance.  All of the rest of staging patchy's
>> operation does not meddle with the work directory of the given
>> repository, does not meddle with the index, and does not meddle with
>> local branches (except for the two branches maintained explicitly for
>> testing).  If it were not for that nonsense, one would not need an extra
>> repository for staging patchy on a cron job.
>
> ok.
>
> Maybe it's better to make test-patches.py run based off
> origin/master instead of master?

test-patches.py as far as I remember is _not_ run based off _either_
origin/master or master, but rather the current _index_.  Which is about
as unreliable as one can get short of just copying the work directory.

One should make it clone origin/master.  Personally, I would give it
different working directories and different locks to the staging patchy
so that they can be run asynchronously.  On the other hand, if one wants
to do things like test-baseline sharing, one will need to meddle with
locks anyway, but the test-baseline building stuff could use its own
build directory and run asynchronously (nice for those people with 8
cores).

If you want to avoid overthinking too much too soon, just use the same
work directory and locking branches.

-- 
David Kastrup