lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]