On Thu, Sep 1, 2016 at 1:27 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Wed, 31 Aug 2016, Sverre Rabbelier wrote: >> On Wed, Aug 31, 2016 at 3:36 AM Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> wrote: >> > On Tue, 30 Aug 2016, Junio C Hamano wrote: >> > > Jeff King <peff@xxxxxxxx> writes: >> > > > Hmm, interesting. Your approach seems reasonable, but I have to wonder >> > > > if writing the pid in the first place is sane. >> > > > >> > > > I started to write up my reasoning in this email, but realized it was >> > > > rapidly becoming the content of a commit message. So here is that >> > > > commit. >> > > >> > > Sounds sensible; if this makes Dscho's "which ones failed in the >> > > previous run" simpler, that is even better ;-) >> > >> > I did not have the time to dig further before now. There must have been a >> > good reason why we append the PID. >> > >> > Sverre, you added that code in 2d84e9f (Modify test-lib.sh to output stats >> > to t/test-results/*, 2008-06-08): any idea why the -<pid> suffix was >> > needed? >> >> I can't really recall, but I think it may have been related to me >> doing something like this: >> 1. Make a change, and start running tests (this takes a long time) >> 2. Notice a failure, start fixing it, leave tests running to find >> further failures >> 3. Finish fix, first tests are still running, start another run in a >> new terminal (possibly of just the one failed test I was fixing) to >> see if the fix worked. >> >> Without the pid, the second run would clobber the results from the first run. >> >> >> If only past-me was more rigorous about writing good commit messages :P. > > :-) > > Would present-you disagree with stripping off the -<pid> suffix, based on > your recollections? No objections, I think it should be fine. If anyone uncovers a particularly compelling reason later on, it's only a commit away :). -- Cheers, Sverre Rabbelier