[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: checking 2240
From: |
David Kastrup |
Subject: |
Re: checking 2240 |
Date: |
Tue, 24 Jan 2012 12:35:17 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Janek Warchoł <address@hidden> writes:
> Hi Julien,
>
> 2012/1/22 Julien Rioux <address@hidden>:
>> Hi Janek,
>> The autoCompile.patch part is defined here:
>> https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L140
>>
>> You'll see that the code uses
>> git apply filename.patch
>> and
>> git apply --reverse filename.patch
>>
>> I think that is what you would like to modify following the suggestions on
>> this thread.
>
> Yes, i've done changes already. Currently i'm stuck at telling github
> to create a nicely formatted patch file which i could send for review
> :/
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.
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.
I suppose we'll get to see the proof when this moves to staging.
So that this does not get needlessly messy in case anything _does_ go
wrong, I am currently in the process of moving the non-controversial
parts of 2240 into staging where they can get advance testing. I
consider it encouraging that only a single snippet from the LSR needed
changing (pushed a new version already that is much simpler and works
either with or without 2240) to compile. I have, however, not compared
the snippets visually.
At some point of time, one should likely revise the snippet database.
There are a _lot_ of snippets that are a show of excellent programming
skills wasted on tasks that could be done a lot simpler. I think it is
important for snippets to be just as complex as the task requires.
--
David Kastrup
- Re: checking 2240 (was: 2.16 release candidate 3 imminent), (continued)
- Re: checking 2240 (was: 2.16 release candidate 3 imminent), address@hidden, 2012/01/22
- Re: checking 2240, David Kastrup, 2012/01/22
- Re: checking 2240, Janek Warchoł, 2012/01/22
- Re: checking 2240, Graham Percival, 2012/01/22
- Re: checking 2240, Janek Warchoł, 2012/01/22
- Re: checking 2240, Janek Warchoł, 2012/01/22
- Re: checking 2240, Graham Percival, 2012/01/22
- Re: checking 2240, Janek Warchoł, 2012/01/22
- Re: checking 2240, Julien Rioux, 2012/01/22
- Re: checking 2240, Janek Warchoł, 2012/01/22
- Re: checking 2240,
David Kastrup <=
- Re: checking 2240, Graham Percival, 2012/01/24
- Re: checking 2240, David Kastrup, 2012/01/24
- Re: checking 2240, David Kastrup, 2012/01/24
- Re: checking 2240, Julien Rioux, 2012/01/24
- Re: checking 2240, Julien Rioux, 2012/01/24
- Re: checking 2240, Graham Percival, 2012/01/24
- Re: checking 2240, Graham Percival, 2012/01/22
- Re: 2.16 release candidate 3 imminent, Graham Percival, 2012/01/21
- Re: 2.16 release candidate 3 imminent, Carl Sorensen, 2012/01/21
- Re: 2.16 release candidate 3 imminent, David Kastrup, 2012/01/21