Re: checking 2240

[Julien Rioux]

On 24/01/2012 6:35 AM, David Kastrup wrote:
> I think the pairing
>
> git apply --index filename.patch
>
> git reset --hard
>
> has less potential to go wrong if there is a problem at any time.  I
> actually don't really understand why we bother with restoring the tree
> anyway instead of removing it and doing the next test from a freshly
> created
>
> git clone
>
> directory.  I am not sure that my problem guess here was correct: git
> apply --reverse should have a better chance of working than git reset
> --hard _iff_ git apply was made without --index option.

The problem guess might not have been correct but it led to serious 
investigations which were indeed needed, so thanks for pointing out the 
problems you faced. We should use a combination that we know is 
bulletproof. At the moment the script uses git apply/git apply 
--reverse. So the patch is applied with git apply patch without --index. 
It's applied to a tree that's created from git checkout-index -a 
--prefix=. In this new tree there is no .git folder and no index.

In certain cases the test script that's currently being run simply skips 
the git apply --reverse part. That would certainly explain what problems 
you have seen, right? That's the biggest problem right now.

> I still am rather sure that the problems Graham sees are with the
> testing setup in some manner.  I created the last diff against master
> _minutes_ after master was updated to staging.  Either a missing update
> or an old version of the rhythmic engraver would explain the symptom
> that I really can't reproduce here.

The script also does not do a git pull before starting the test runs. 
Could explain other problems that you have seen.

> I suppose we'll get to see the proof when this moves to staging.

Regards,
Julien