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@gmail.com> ---
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(-)
Show changes to git-gui.sh +1 −1
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
