Re: LILY-GIT PITA

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> From: "James" <address@hidden>
> To: "Devel" <address@hidden>
>>
>> Am i the only one using lily-git.tcl of the *active* dev team?

It's possible.

>> I ask because since it was changed a couple of years or so ago that
>> it *always* assumes you want/need to be on dev/local_working it
>> really makes it a PITA for me to work with.

If it's strictly worse than before for its sole user, reverting that
change seems like a no-brainer.

>> I have do some stuff I have no idea how to do to merge or rebase or
>> branch or some such stuff just to get a patch formed.
>>
>> I've managed to screw up my LILYPOND_GIT dir twice now - headless
>> with merge conflicts on a load of files I have not even any interest
>> in.

git merge --abort or git rebase --abort will usually do the trick for
cleaning up a mess in progress.

If the mess has commenced to final state, git reflog shows points one
can return to by specifying them after git reset --hard on the command
line.

>> It's wasted time (and it is a wasted because I have learned nothing
>> doing this) and end up restoring my *whole LilyDev VM* just to get a
>> clean set of trees. Yes I can just download the source only but then
>> I have to screw about with my git config and ssh and all that jazz
>> and it's just easier to restore a VM from a backup frankly and then
>> pull.
>>
>> If I am the only one using this tcl utility - and I think I am.
>>
>> Can someone just put it back so that it can create a patch and amend
>> existing commit based on the branch I am on *now* not what it thinks
>> I should be on?

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.

In the respective commit I read
commit 0a1bb6351826eb3d0d857d5dedf707f8ba58d920
Author: Carl Sorensen <address@hidden>
Date:   Wed Dec 28 22:49:17 2011 -0700

    Update lilygit.tcl (Issue 2092)
    
    Makes lilygit.tcl respect the environment variable $LILYPOND_GIT.
    If $LILYPOND_GIT is unset, default of $HOME/lilypond-git will be used.
    
    Also does all working on dev/local_working branch, instead of master
    
    Adds a Push Patch button to push patch to staging, which is optionally
    configured, such that it only displays if push access is available
    and the user is not a translations user.
    
    Add support for the environment variable LILYPOND_BRANCH, which can
    be prepended to the call to lily-git.tcl to specify the branch to be used.
    
    Add pushHead so we can base patches on master but push to staging
    
    Add log preview so that the user is expected to review the git log before
    pushing.
    
    Rebase before pushing.  The rebasing is to origin/staging,
    and is performed on a detached head before pushing.  This preserves the
    working branch in case of staging breaking and being recreated.
    
    Add environment variable PUSH_ACCESS for controlling push access

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.

>> 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.
>
> I used to be a big lily-git user, but now rarely do.  That's not
> because I found it messed me about, but because I learnt enough not to
> need it.  I've learnt the git commit syntax and the git patch syntax
> (generally git format-patch origin/master, iirc) well enough not to
> need it.  So if there are problems with it, they don't hit me, I'm
> afraid.  I also find gitk is my friend.

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 should be a red flag that other non-specific git tools don't try
suggesting or enforcing anything like this.

I'm currently swamped in so many tasks that learning Tcl and maintaining
another piece of software that I'm not actually using would be really a
hit on my productivity.

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
would appear that at the current point of time, just rowing back some
selected changes will already accomplish a lot.

-- 
David Kastrup