Graham Percival <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
