If a text widget is asked the index at x,y with y == 0 or y == 1 it will
always return 1.0 as the nearest index, regardless of the x position.
This means that clicking the top 2 pixels of the Unstaged/Staged Changes
lists caused the state of the file there to be toggled. This patch
checks that the pixel clicked is greater than 1, so there is less chance
of accidentally staging or unstaging changes.
Signed-off-by: Richard Quirk <richard.quirk@xxxxxxxxx>
---
To test the unpatched changes, make a change in a git-controlled repo and run
git-gui. Click the Unstaged Changes list away from the first column, but near
(within 1 pixel) to the pink header part. The file underneath is staged, rather
surprisingly. Similarly, for staged files click a pixel or 2 underneath the
green Staged Changes header and the changes are unstaged, even if the first
column is not clicked.
This change looks like a hack - but I'm pretty sure it's a bug in the Tk text
widget that's causing the strange behaviour. I couldn't see any other way to
fix this accidental (un)staging, which seems to get me at least once a day
lately.
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 23d7dfe..980dc0b 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1797,7 +1797,7 @@ proc toggle_or_diff {w x y} {
$ui_index tag remove in_sel 0.0 end
$ui_workdir tag remove in_sel 0.0 end
- if {$col == 0} {
+ if {$col == 0 && $y > 1} {
set i [expr {$lno-1}]
set ll [expr {[llength $file_lists($w)]-1}]
--
1.5.6.9.g26943
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
