Hi Sverre, On Wed, 31 Aug 2016, Sverre Rabbelier wrote:
> On Wed, Aug 31, 2016 at 3:36 AM Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > On Tue, 30 Aug 2016, Junio C Hamano wrote: > > > Jeff King <p...@peff.net> 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? Ciao, Dscho
