On 11/29/13 12:52 PM, "James" <[email protected]> wrote:
> >1. Git checkout [branch] on the command line. That's fine I can handle >that :) > >Where [branch] is going to be Staging 99% of the time (but for the case >where I whined, it was stable/2.18) > >2. Then run lily-git.tcl from the same session which keeps me on the >branch, and click the 'update source' button which I think does a pull >or some-such thing.= > >3. Then I make my edit to whatever tely file needs changing. > >4. Then I would click the 'New local commit' button to pop up that UI >that I write all the summary/details in it. > >5. Then I would click the 'make patch set' button to get my patch. > >5a: Run git-cl to upload patch set for review. > >6. Then I would click the 'Abort Changes Reset to Origin' button which >removes my commit (the patch still exists remember) > >done. > >I then work on the next item and have a new patch for that, aborting >after I create that. > >heh.. I'm probably making a lot of the skilled git users flinch with my >method. > >But basically I am managing patches instead of branches and yes I am >happy to keep 'rebasing' patches by applying them, amending the last >commit and making a new patch set. It is clunky but it seems simple. > >I hope that isn't too much work, but that the old way of lily-git seemed >to work OK. James, I'm sorry I haven't finished this yet. I've been spending some time investigating and mulling through possible solutions. lily-git.tcl is *intentionally* hard-coded to always do patches from master rebased onto staging. That is, it makes things work properly for the standard user flow. This is related to David K.'s assertion that it should know about the lilypond tree and workflow. In fact, it does. I really don't think we should make lily-git.tcl less aware of the desired workflow. I've thought of some possible fixes: 1) Add an "expert mode" button that then would open up a listbox that would allow you to choose your branch. 2) Create a special, branch-unaware version of lily-git.tcl that would always work on the current branch. 3) Create some special shell commands that will do just what you want, and give them to you directly. At the moment, I'm leaning towards 3, as it's the least-effort way to go. What do you think? Thanks, Carl _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
