"Phil Holmes" <[email protected]> writes: > From: "James" <[email protected]> > To: "Devel" <[email protected]> >> >> 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 <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
