Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
LGTM http://codereview.appspot.com/5504092/diff/20001/scripts/auxiliar/lily-git.tcl File scripts/auxiliar/lily-git.tcl (right): http://codereview.appspot.com/5504092/diff/20001/scripts/auxiliar/lily-git.tcl#newcode248 scripts/auxiliar/lily-git.tcl:248: git remote add -t $originHead \ This should change to git clone, but that can happen in a later edit. Let's get this first change pushed. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Some questions and concerns.
thanks,
Janek
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl
File scripts/auxiliar/lily-git.tcl (right):
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode222
scripts/auxiliar/lily-git.tcl:222: proc update_lilypond_norebase {} {
this isn't used anywhere, we keep it just in case?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode252
scripts/auxiliar/lily-git.tcl:252: if {$workingBranch != } {
Do i understand correctly that we check workingBranch and switch to
working on it if it's not empty? So, if we don't want to work on
workingBranch, we set it to null and lily-git will remain on OriginHead
(i.e. master)?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode253
scripts/auxiliar/lily-git.tcl:253: add_working_branch
Won't this reset our workingBranch to be a copy of master every time we
update repository?
Wait, i see: it's done only when creating new repository?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode270
scripts/auxiliar/lily-git.tcl:270: git rebase origin/$originHead
shouldn't we update local master too?
If we don't do this, how can we not run into trouble in line 309?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode272
scripts/auxiliar/lily-git.tcl:272: git merge origin/$originHead
Shouldn't we checkout workingBranch first (after checking if it exists)?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode309
scripts/auxiliar/lily-git.tcl:309: git rebase $originHead
isn't there a risk that master is less up-to-date than working-branch?
(see comment on line 270)
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode560
scripts/auxiliar/lily-git.tcl:560: if [catch {set workingBranch
$env(LILYPOND_BRANCH)}] {
does this mean it there's no external variable to control
workingBranch?
http://codereview.appspot.com/5504092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Hello On 21 January 2012 21:12, janek.lilyp...@gmail.com wrote: Some questions and concerns. While I don't understand any of this really, isn't lily-git.tcl supposed to be for git-idiots (like me) who don't even want to think about branches? :) Just wondering if Janek is 'overthinking' this - apologies if not. Also @carl, could we make lilygit-tcl (not this patch) with a text area I can *paste* into (and/or ctrl-v) as I cannot do that with the current iteration, I can only type into it. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
2012/1/21 James pkx1...@gmail.com: Hello On 21 January 2012 21:12, janek.lilyp...@gmail.com wrote: Some questions and concerns. While I don't understand any of this really, isn't lily-git.tcl supposed to be for git-idiots (like me) who don't even want to think about branches? :) That's exactly why they should work themselves, not needing you to fix them when they fail :) Being fool-proof requires extra tricks sometimes, hidden under the hood. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 1/21/12 5:36 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: 2012/1/21 James pkx1...@gmail.com: Hello On 21 January 2012 21:12, janek.lilyp...@gmail.com wrote: Some questions and concerns. While I don't understand any of this really, isn't lily-git.tcl supposed to be for git-idiots (like me) who don't even want to think about branches? :) That's exactly why they should work themselves, not needing you to fix them when they fail :) Being fool-proof requires extra tricks sometimes, hidden under the hood. And I believe the current patch *is* foolproof. Have you found an error? If so, can you demonstrate what you have done to reproduce the error? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Nice review.
I will make changes in response to your comments.
Thanks,
Carl
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl
File scripts/auxiliar/lily-git.tcl (right):
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode222
scripts/auxiliar/lily-git.tcl:222: proc update_lilypond_norebase {} {
On 2012/01/21 21:12:58, janek wrote:
this isn't used anywhere, we keep it just in case?
Looks like it can go. Thanks for the catch.
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode252
scripts/auxiliar/lily-git.tcl:252: if {$workingBranch != } {
On 2012/01/21 21:12:58, janek wrote:
Do i understand correctly that we check workingBranch and switch to
working on
it if it's not empty? So, if we don't want to work on workingBranch,
we set it
to null and lily-git will remain on OriginHead (i.e. master)?
No. workingBranch should never be null. If it is, we'll get lots of
git errors. So if workingBranch is null, we don't do any checking out.
No. $workingBranch should never be null. If you try to ch
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode253
scripts/auxiliar/lily-git.tcl:253: add_working_branch
On 2012/01/21 21:12:58, janek wrote:
Won't this reset our workingBranch to be a copy of master every time
we update
repository?
Wait, i see: it's done only when creating new repository?
Precisely.
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode270
scripts/auxiliar/lily-git.tcl:270: git rebase origin/$originHead
On 2012/01/21 21:12:58, janek wrote:
shouldn't we update local master too?
If we don't do this, how can we not run into trouble in line 309?
Ahh. I see what you mean. Before we were only rebasing master to
origin/master. Then we changed to rebasing workingBranch to
origin/master.
We should be rebasing master to origin/master, and then workingBranch to
master.
Thanks for the catch.
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode560
scripts/auxiliar/lily-git.tcl:560: if [catch {set workingBranch
$env(LILYPOND_BRANCH)}] {
On 2012/01/21 21:12:58, janek wrote:
does this mean it there's no external variable to control
workingBranch?
Yes. Strictly speaking it means If there is an error in setting the
value of the local variable workingBranch to the environment variable
LILYPOND_BRANCH.
http://codereview.appspot.com/5504092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
LGTM http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
New version of lilygit.tcl that: 1. Treats staging properly -- i.e. does not create a local staging branch 2. Does rebase before pushing patch on a detached head (as now described in cg patch) 3. Has an environment variable setting push access, so no editing of the file is necessary (which makes for easy updates) Please review http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
http://codereview.appspot.com/5504092/diff/8001/scripts/auxiliar/lily-git.tcl File scripts/auxiliar/lily-git.tcl (right): http://codereview.appspot.com/5504092/diff/8001/scripts/auxiliar/lily-git.tcl#newcode13 scripts/auxiliar/lily-git.tcl:13: set push_access 1 This must be set to 0. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
After commenting out the git push line, and also disconnecting my network cable, then going to push patch, I get this: fatal: ambiguous argument 'staging..dev/local_working': unknown revision or path not in the working tree. Use '--' to separate paths from revisions Look, could we just treat this as three separate stages? 1. update lily-git.tcl to use $LILYPOND_GIT and use dev/local-staging. 2. get the git instructions for the command-line nailed down (issue 2100). 3. if it's still relevant, work on adding push ability to lily-git.tcl. Having a really good set of instructions in step 2 will make #3 easier -- and there's no point delaying #1 for another few weeks when AFAIK that part is perfect. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2012/01/14 09:31:39, Graham Percival wrote: Look, could we just treat this as three separate stages? 1. update lily-git.tcl to use $LILYPOND_GIT and use dev/local-staging. 2. get the git instructions for the command-line nailed down (issue 2100). 3. if it's still relevant, work on adding push ability to lily-git.tcl. We could, but I don't think we need to. Your problem was that your repository was missing staging, and I didn't have it being created automatically. It is now created properly and automatically. So 1 and 3 are done with this patch (and 3 can be easily disabled by leaving push_access at 0). I will get 2 done today. Thanks, Carl http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
The problem is not merges. The problem is unintentional merges. merges _from_ staging (or origin/staging) are usually a mistake. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
LGTM apart from one detail http://codereview.appspot.com/5504092/diff/5001/scripts/auxiliar/lily-git.tcl File scripts/auxiliar/lily-git.tcl (right): http://codereview.appspot.com/5504092/diff/5001/scripts/auxiliar/lily-git.tcl#newcode295 scripts/auxiliar/lily-git.tcl:295: git push origin HEAD:$pushHead I'm still concerned about this type of automatic pushing. The revised CG material on branches http://codereview.appspot.com/5484043/ makes a bit deal about always checking gitk -- just for 5 seconds -- before pushing, and I think that's a good step. Patchy will not question any ridiculous git history that arises due to any kind of weird series of commands in git. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/30 20:57:02, Graham Percival wrote: Patchy will not question any ridiculous git history that arises due to any kind of weird series of commands in git. Maybe it would make sense if Patchy refused fast forwarding over a history involving a merge _from_ staging. I think that merges should just be from master; a merge from staging implies a merging pull, and I can't think of a situation where we would want to see those in the history of master. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/30 20:57:02, Graham Percival wrote: LGTM apart from one detail http://codereview.appspot.com/5504092/diff/5001/scripts/auxiliar/lily-git.tcl#newcode295 scripts/auxiliar/lily-git.tcl:295: git push origin HEAD:$pushHead I'm still concerned about this type of automatic pushing. The revised CG material on branches http://codereview.appspot.com/5484043/ makes a bit deal about always checking gitk -- just for 5 seconds -- before pushing, and I think that's a good step. Patchy will not question any I think I can achieve that automatically by looking at the commit log between staging and working. If there are no merge commits in that log, we are good to push IIUC. I ought to be able to check for that automatically and only do the push if there are no problems. I'll try to cook a revised patch in a bit. Thanks for the review. Carl http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On Sat, Dec 31, 2011 at 12:10:14AM +, carl.d.soren...@gmail.com wrote: On 2011/12/30 20:57:02, Graham Percival wrote: I'm still concerned about this type of automatic pushing. The revised CG material on branches http://codereview.appspot.com/5484043/ makes a bit deal about always checking gitk -- just for 5 seconds -- before pushing, and I think that's a good step. Patchy will not question any I think I can achieve that automatically by looking at the commit log between staging and working. If there are no merge commits in that log, we are good to push IIUC. Hmm. Could I interest you in adding some checks to Patchy? I'd rather have that complexity in Patchy rather than lily-git.tcl -- that way, it doesn't matter if anything weird happens on a command-line or within lily-git; we're still protected. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/29 06:45:53, Graham Percival wrote: First thought: I'm a bit leery of adding a push to staging, since: 1. that clutters up the interface. Sure, it's just one more button, but OTOH that's 25% more buttons. :) It would seem to me that this button need only appear when you have told the configuration (is there one?) that you are a developer. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Graham, can you ping me when changes to lily-git.tcl are finalized and I'll get new version into lilydev-remix image. Thanks, Jon 2011/12/29 Janek Warchoł janek.lilyp...@gmail.com: 2011/12/29 pkx1...@gmail.com: On 2011/12/29 08:31:38, dak wrote: It would seem to me that this button need only appear when you have told the configuration (is there one?) Not for lily-git.tcl specifically, but there _is_ something it checks wen you run it; for instance if you use it for the very first time it knows you have not done (effectively) git config --global user.name/user.email and prompts you to fill in those two entries by popping up a small GUI to fill in. So for push access lilygit could check for the 'ssh://' line in .git/config as, according to the CG, you have to set up for ssh with git manually anyway. So I am assuming that without this line in the .git/config you couldn't push even if you were an experienced dev. Then maybe the button could be greyed out (like they all are except 'update' the very first time you run it). +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Jonathan Kulp http://jonathankulp.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/29 18:19:26, Graham Percival wrote: On Thu, Dec 29, 2011 at 05:21:34PM +, mailto:carl.d.soren...@gmail.com wrote: The Push button is disabled by default; an experienced user can enable it with a simple edit to the script. By disabled, do you mean commented out ? If new contributors see a greyed-out button, they'll get confused and ask silly questions. The UI should be designed to avoid silly questions[1]. On 2011/12/29 18:19:26, Graham Percival wrote: On Thu, Dec 29, 2011 at 05:21:34PM +, mailto:carl.d.soren...@gmail.com wrote: The Push button is disabled by default; an experienced user can enable it with a simple edit to the script. By disabled, do you mean commented out ? If new contributors see a greyed-out button, they'll get confused and ask silly questions. The UI should be designed to avoid silly questions[1]. By disabled, I mean it doesn't appear. It isn't commented out, but it's not put into the user interface unless push_access is set to 1. I've also added support for an environment variable specifying the branch. This will allow lily-git users to work with more than one patch simultaneously by doing LILYPOND_BRANCH=dev/fix-my-issue lilypond-git.tcl hmm. I'll come back to this later. If this is not used, the branch defaults to dev/local_working. The environment variable is not needed and can easily be ignored by novices. This is definitely not right; please branch off of master. We have absolutely no guarantee that staging will compile the binary, let alone the documentation. I guess that is true. In my work, I always branch off staging, because that is where I will have to push it. So I can see that the working branch should be off master, and then when pushing we should rebase off staging. i will fix that. Thanks for the review. Carl http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On Thu, Dec 29, 2011 at 05:21:34PM +, carl.d.soren...@gmail.com wrote: The Push button is disabled by default; an experienced user can enable it with a simple edit to the script. By disabled, do you mean commented out ? If new contributors see a greyed-out button, they'll get confused and ask silly questions. The UI should be designed to avoid silly questions[1]. [1] actually, in this case it would be a sensible question rather than silly -- so IMO it's an even better idea to change the UI if it gives misleading suggestions. I've also added support for an environment variable specifying the branch. This will allow lily-git users to work with more than one patch simultaneously by doing LILYPOND_BRANCH=dev/fix-my-issue lilypond-git.tcl hmm. I'll come back to this later. and they will work on that branch. If the branch doesn't exist it will be created off of staging. This is definitely not right; please branch off of master. We have absolutely no guarantee that staging will compile the binary, let alone the documentation. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
2011/12/29 pkx1...@gmail.com: On 2011/12/29 08:31:38, dak wrote: It would seem to me that this button need only appear when you have told the configuration (is there one?) Not for lily-git.tcl specifically, but there _is_ something it checks wen you run it; for instance if you use it for the very first time it knows you have not done (effectively) git config --global user.name/user.email and prompts you to fill in those two entries by popping up a small GUI to fill in. So for push access lilygit could check for the 'ssh://' line in .git/config as, according to the CG, you have to set up for ssh with git manually anyway. So I am assuming that without this line in the .git/config you couldn't push even if you were an experienced dev. Then maybe the button could be greyed out (like they all are except 'update' the very first time you run it). +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
I've uploaded a new patch set. The Push button is disabled by default; an experienced user can enable it with a simple edit to the script. I couldn't find a good value that I believed would work for automatic detection, since my push-enabled configuration is different from that listed in the CG. I've also added support for an environment variable specifying the branch. This will allow lily-git users to work with more than one patch simultaneously by doing LILYPOND_BRANCH=dev/fix-my-issue lilypond-git.tcl and they will work on that branch. If the branch doesn't exist it will be created off of staging. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/29 08:31:38, dak wrote: It would seem to me that this button need only appear when you have told the configuration (is there one?) Not for lily-git.tcl specifically, but there _is_ something it checks wen you run it; for instance if you use it for the very first time it knows you have not done (effectively) git config --global user.name/user.email and prompts you to fill in those two entries by popping up a small GUI to fill in. So for push access lilygit could check for the 'ssh://' line in .git/config as, according to the CG, you have to set up for ssh with git manually anyway. So I am assuming that without this line in the .git/config you couldn't push even if you were an experienced dev. Then maybe the button could be greyed out (like they all are except 'update' the very first time you run it). Just a thought. James http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update lilygit.tcl (Issue 2092) (issue 5504092)
Reviewers: ,
Message:
Here's a stab at revising lily-git.tcl to facilitate patch pushing by
git novices.
Please review.
Thanks,
Carl
Description:
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.
Please review this at http://codereview.appspot.com/5504092/
Affected files:
M scripts/auxiliar/lily-git.tcl
Index: scripts/auxiliar/lily-git.tcl
diff --git a/scripts/auxiliar/lily-git.tcl b/scripts/auxiliar/lily-git.tcl
index
6f16791313d94a5aa83bfe7742406c16fff93e37..46740b35cbee4a56768baa33d5162dde48bd6a2e
100755
--- a/scripts/auxiliar/lily-git.tcl
+++ b/scripts/auxiliar/lily-git.tcl
@@ -4,13 +4,15 @@
# Copyright 2009--2011 by Johannes Schindelin and Carl Sorensen
#
-set version 0.64
+set version 0.65
# set to 1 to set up for translation, to 0 for other
set translator 0
# location of lilypond git
-set lily_dir $env(HOME)/lilypond-git
+if [catch {set lily_dir $env(LILYPOND_GIT)}] {
+ set lily_dir $env(HOME)/lilypond-git
+}
if {$translator == 1} {
set windowTitle \
@@ -24,7 +26,8 @@ if {$translator == 1} {
LilyPond Contributor's Git Interface version $version
set updateButtonText 1. Update source
set initializeButtonText 1. Get source
-set originHead master
+set originHead staging
+set workingBranch dev/local_working
set rebase 1
}
package require Tk
@@ -215,6 +218,7 @@ proc update_lilypond {rebase} {
global lily_dir
global originHead
global translator
+global workingBranch
. config -cursor watch
if {![file exists $lily_dir]} {
write_to_output Cloning LilyPond (this can take some time) ...\n
@@ -228,16 +232,22 @@ proc update_lilypond {rebase} {
git reset --hard origin/$originHead
git config branch.$originHead.remote origin
git config branch.$originHead.merge refs/heads/$originHead
+if {$workingBranch != } {
+ git branch -f $workingBranch
+ git checkout $workingBranch
+}
.buttons.commitFrame.commit configure -state normal
.buttons.commitFrame.amend configure -state normal
.buttons.update configure -text buttonUpdateText
.buttons.patch configure -state normal
+.buttons.push configure -state normal
.buttons.panic configure -state normal
toggle_rebase
} else {
write_to_output Updating LilyPond...\n
git fetch origin
if {$rebase} {
+git checkout $workingBranch
git rebase origin/$originHead
} else {
git merge origin/$originHead
@@ -267,6 +277,16 @@ proc make_patch_from_origin {rebase} {
. config -cursor
}
+
+proc push_patch_to_staging {} {
+global workingBranch
+global originHead
+
+git checkout $workingBranch
+git rebase $originHead
+git push origin HEAD:$workingBranch
+}
+
proc abort_changes {} {
global abort_dir
global originHead
@@ -396,6 +416,8 @@ button .buttons.update -text $updateButtonText \
-command update_lilypond_with_rebase
button .buttons.patch -text 3. Make patch set \
-command patch_from_origin
+button .buttons.push -text 4. Push patch to staging \
+-command push_to_staging
toggle_rebase
button .buttons.panic -text Abort changes -- Reset to origin \
-command abort_changes -fg Blue -bg Red
@@ -406,6 +428,7 @@ if {![file exists $lily_dir]} {
.buttons.commitFrame.commit configure -state disabled
.buttons.commitFrame.amend configure -state disabled
.buttons.patch configure -state disabled
+.buttons.push configure -state disabled
.buttons.panic configure -state disabled
}
@@ -414,6 +437,7 @@ if {![file exists $lily_dir]} {
pack .buttons.update -side left
pack .buttons.commitFrame -side left
pack .buttons.patch -side left
+pack .buttons.push -side left
pack .buttons.spacer -side left
pack .buttons.panic -side right
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Thanks for working on this! Unfortunately I'm between cities at the moment; I'll try to comment more tomorrow evening. First thought: I'm a bit leery of adding a push to staging, since: 1. that clutters up the interface. Sure, it's just one more button, but OTOH that's 25% more buttons. :) 2. it might confuse new contributors, who aren't allowed to push to staging. 3. anybody who's stayed around long enough to get git push ability shouldn't need it. (particularly once I get around to working on my cg patch again) http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
