On 07/12/13 18:33, Carl Sorensen wrote:
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
Carl,
I hadn't been ignoring this I had decided to go back and look again at
Lily-git.tcl and try to get to grips with it.
Hence the fair few number of patches done in the last week or so I have
managed to do.
I understand the 'workflow' much better than I did before. I do thank
you for the offer of creating some 'special' shell commands and/or
branch-unaware versions, but I think that would - at least now - be
unnecessary work that I no longer need.
There are some quirks (for me) that might be easier to explain or
resolve as a 'non git-fu-er' such as:
It seems that the 'update source' button doesn't update staging, only
master, so I always have to run git checkout staging, git pull and then
merge staging manually with dev/local_working.
As we eventually push to staging (and not master) and as staging should
theoretically always be the same as (or ahead of) master, that updating
staging rather than master would make more sense? Or perhaps just do
both trees.
Also I don't know if we can automate the merging of staging with
dev/local_working (or if that is dangerous to do) so that the two are
always the same? As I have a very primitive kind of workflow there may
be problems doing that.
Otherwise, now that I am more 'used to' working on dev/local working
(even if I as a simple user don't really need that tree, but understand
that others might have a use for it) and only seem to have issues if I
am checked out in (?) a branch not staging or master (i.e. such as
stable/2.18) where lily-git cannot make patches for, unless I assume I
merge dev/local with 2.18 but if 2.18 and staging are different then I
am going to get confused no doubt :)
So in those 'one-off' cases I can just check in to staging and ask
someone to cherry pick to 2.18.
James
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
