On 11/29/13 12:52 PM, "James" <address@hidden> 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