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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
