lsearch and lreplace both take the variable content as argument and not
just their name.
Signed-off-by: Heiko Voigt <redacted>
---
lib/remote.tcl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
From: Pat Thoyts <hidden> Date: 2016-06-15 22:50:33
On 12 February 2011 16:43, Heiko Voigt [off-list ref] wrote:
quoted hunk
lsearch and lreplace both take the variable content as argument and not
just their name.
Signed-off-by: Heiko Voigt <redacted>
---
lib/remote.tcl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
unset repo_config(remote.$name.push)
}
- set i [lsearch -exact all_remotes $name]
- lreplace all_remotes $i $i
+ set i [lsearch -exact $all_remotes $name]
+ set all_remotes [lreplace $all_remotes $i $i]
set remote_m .mbar.remote
delete_from_menu $remote_m.fetch $name
--
1.7.4.34.gd2cb1
This fix is good and clearly resolves a bug in the tcl code --
however, what does it actually fix in the application? It looks like
removing a remote works anyway even though this variable is not being
updated.
Pat Thoyts
Hi Pat,
On Sun, Feb 13, 2011 at 01:20:14PM +0000, Pat Thoyts wrote:
This fix is good and clearly resolves a bug in the tcl code --
however, what does it actually fix in the application? It looks like
removing a remote works anyway even though this variable is not being
updated.
I do not know the other implications but I needed this fix for a patch I
wrote. I did not send it because it is quite long and I wanted to wait
until my other patches are ok so you do not have to review too much.
But since you asked I will reply with the two patches to this email.
Cheers Heiko
The commandline fetch already has this option for some time. Since this
was not available at the time git gui was written lets implement it now.
Signed-off-by: Heiko Voigt <redacted>
---
It just came to my mind that I probably should implement a version check
of the commandline to ensure that this option is available. Thats why I
tagged only this patch with RFC.
Cheers Heiko
lib/remote.tcl | 45 +++++++++++++++++++++++++++++++++++++++++++++
lib/transport.tcl | 29 +++++++++++++++++++++++++++++
2 files changed, 74 insertions(+), 0 deletions(-)
@@ -281,4 +324,6 @@ proc remove_remote {name} {delete_from_menu$remote_m.remove$name# Not all remotes are in the push menucatch{delete_from_menu$remote_m.push$name}++update_all_remotes_menu_entry}
@@ -20,6 +20,35 @@ proc prune_from {remote} {console::exec$w[listgitremoteprune$remote]}+procfetch_from_all{}{+setw[console::new\+[mc"fetch all remotes"]\+[mc"Fetching new changes from all remotes"]]++setcmd[listgitfetch--all]+if{[is_config_truegui.pruneduringfetch]}{+lappendcmd--prune+}++console::exec$w$cmd+}++procprune_from_all{}{+globalall_remotes++setw[console::new\+[mc"remote prune all remotes"]\+[mc"Pruning tracking branches deleted from all remotes"]]++setcmd[listgitremoteprune]++foreachr$all_remotes{+lappendcmd$r+}++console::exec$w$cmd+}+procpush_to{remote}{setw[console::new\[mc"push %s"$remote]\
Hi Pat,
On Sun, Feb 13, 2011 at 01:20:14PM +0000, Pat Thoyts wrote:
On 12 February 2011 16:43, Heiko Voigt [off-list ref] wrote:
quoted
lsearch and lreplace both take the variable content as argument and not
just their name.
Signed-off-by: Heiko Voigt <redacted>
---
lib/remote.tcl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
unset repo_config(remote.$name.push)
}
- set i [lsearch -exact all_remotes $name]
- lreplace all_remotes $i $i
+ set i [lsearch -exact $all_remotes $name]
+ set all_remotes [lreplace $all_remotes $i $i]
If you were going to please wait with applying it. I just found another
location where this variable is changed in a wrong manner. I will update
the patch accordingly.
Cheers Heiko
Hi Pat,
On Sun, Feb 13, 2011 at 03:05:23PM +0100, Heiko Voigt wrote:
If you were going to please wait with applying it. I just found another
location where this variable is changed in a wrong manner. I will update
the patch accordingly.
Please forget this comment. I mistakenly found an lappend call with the
same usage pattern, but for lappend this is obviously correct.
Cheers Heiko
The commandline fetch already has this option for some time. Since this
was not available at the time git gui was written lets implement it now.
I really like this feature, I wanted to have that for quite some time!
After testing it, I noticed two minor things:
1) It would be nice if the new menu entry would only appear when there
is more than one remote to fetch from.
2) I would rather like to see it at the *end* of the submenu, not at the
beginning. Being used to always click on the first menu entry only
to learn that the remote that used to be there got with something
else is kind of surprising ;-)
What do others think?
In case there is only one remote a fetch/prune all entry
is redundant.
Signed-off-by: Heiko Voigt <redacted>
---
On Tue, Feb 22, 2011 at 07:36:23PM +0100, Jens Lehmann wrote:
1) It would be nice if the new menu entry would only appear when there
is more than one remote to fetch from.
How about this? Disclaimer: Only superficially tested on OSX.
lib/remote.tcl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
The user might have got used to the order the remotes appeared previously.
Lets add the all entry last so the all entry does not confuse previous
users.
Signed-off-by: Heiko Voigt <redacted>
---
On Tue, Feb 22, 2011 at 07:36:23PM +0100, Jens Lehmann wrote:
2) I would rather like to see it at the *end* of the submenu, not at the
beginning. Being used to always click on the first menu entry only
to learn that the remote that used to be there got with something
else is kind of surprising ;-)
And this? Disclaimer: Also only superficially tested on OSX.
lib/remote.tcl | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
The user might have got used to the order the remotes appeared previously.
Lets add the all entry last so the all entry does not confuse previous
users.
Signed-off-by: Heiko Voigt <redacted>
I tested both patches under Linux, looks great now.
Tested-by: Jens Lehmann <redacted>