[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LILY-GIT PITA
From: |
Carl Sorensen |
Subject: |
Re: LILY-GIT PITA |
Date: |
Thu, 28 Nov 2013 14:52:52 +0000 |
User-agent: |
Microsoft-MacOutlook/14.3.8.130913 |
On 11/28/13 3:33 AM, "David Kastrup" <address@hidden> wrote:
>"Phil Holmes" <address@hidden> writes:
>
>> From: "James" <address@hidden>
>> To: "Devel" <address@hidden>
>>>
>>>We have the problem that lily-git.tcl is a "well-meant" tool. The
>people who have written and changed it are not the people using it.
>That's a recipe for trouble because it means deficiencies in every-day
>use will not be seen by the persons who are in the situation to change
>it.
This is true. It was written to Graham's specifications.
>
>That would suggest that using a particular branch would require writing
>
>LILYPOND_BRANCH=[name of the branch] lily-git.tcl
>
>If we have a single-user tool, maybe it would be worth revisiting the
>changes and the implied workflows. Carl, any ideas about what makes
>sense here? There seems to be enough in this particular patch that
>reverting all of it would appear excessive.
I will be happy to fix this, at least in a rudimentary way. We have
pushHead defined, so we can play with that variable.
>
>>> It really has put me off making any more doc contributions because I
>>> end up having to relearn all the git cli each time as I don't live
>>> and breathe git and the instructions in the CG assume some broad
>>> knowledge that I don't have. It's become a game of luck as to
>>> whether I end up with a patch or a borked tree.
>>>
>>> I don't develop separate branches and those that are skilled enough
>>> to do that don't use Lily-git.tcl.
James, if you will share with me the problems you are having, I'll try to
make it work for you.
>The main advantage that lily-git.tcl should have over one of the
>abundant git helpers around nowadays is that its knowledge of branches
>and their layout and policies can be specific to LilyPond. The
>dev/local_working idea seems inflexible, bad for working on more than
>one patch at once, and not specific to LilyPond.
It was intended to be inflexible, because the flexibility of git was one
of the main obstacles to its use (for a novice). In fact, that's what you
see in James's comments -- he doesn't want to learn git. He just wants to
push the buttons and have things work right.
Of course, he doesn't want things to work *wrong* when he pushes the
buttons.
>
>Hampering James, however, is also a really bad hit for LilyPond. Is
>there anybody who'd be willing to work with James in getting
>lily-git.tcl into a shape where it's more flexible and easy to use?
It's probably a question of adding a bit of flexibility and maintaining
the current ease of use.
> It
>would appear that at the current point of time, just rowing back some
>selected changes will already accomplish a lot.
I actually don't believe that rowing back those changes will fix things.
But if they do, I'm certainly willing to do it.
Thanks,
Carl