lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

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