critical: git-gui for Windows: multiple selections in the unstaged change panel not honored

[zosrothko]

• I was not able to find an open or closed issue matching what I'm seeing

Theis issue is about Git-Gui Version 2.11.0.windows.1 while this was working in the previous 2.10 version. This is quite annoying since when there are many files, one should stage them one by one instead of many of them using the windows ctrl/maj key. Thus I had to reinstall the 2.10.2 version.

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit? 64 bit

Z:\git\SPLC>git --version --build-options
git version 2.11.0.windows.1
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Z:\git\SPLC> cmd.exe /c ver

Microsoft Windows [version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
Z:\git\SPLC> type "C:\Program Files\Git\etc\install-options.txt"
Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Difftool: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

TODO

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

cmd.exe

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

In the Unstaged Changes panel, select more than one lines, then press <ctrl><T> to stage all selected files. 

• What did you expect to occur after running these commands?

All selected lines should be staged

• What actually happened instead?

Only one file is staged.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

not relevant

[dscho]

I suspect that this is not a Windows-specific issue, but have currently no chance to follow up on that hunch.

Maybe report it to the Git mailing list would make this issue resolved quicker.

[kju]

Can confirm this issue

[jasonkenneth]

This has been driving me nuts. Thanks for logging the issue.

[PhilipOakley]

What is the Gui version ? - the 'help>about' will give the git version, gui version and tcl version, etc.

The crtl / shift selection works on my hack ubuntu laptop (an old XP DELL Lattitude D620 - works well! - try it if you have an old defunkt laptop), so it's not looking like an upstream issue, though I may not have tried a sufficient test (is it just the selection that is needed to demo the issue?)
[my sys: Gui 0.2.0.0.44.gccc98; git 2.11.0.2.28.gde2efeb; tcl 8.6.5; Aspell 0.60.7-20110707.en_GB]

What does work? Do the ctrl / shft keys work (at all) in the other panes, or are they globally disabled (which could suggest an msys2 issue).

Also have you tried the https://github.com/git-for-windows/git/releases/tag/v2.11.1.windows-prerelease.1 just in case it is releated (bad special character processing...)

[jasonkenneth]

I have git-gui version 0.21.GITGUI
git version 2.11.0.windows.1
Tcl/Tk version 8.6.6

I am on Windows 7.

My workflow is this in either the unstaged or staged window panes:

1. click file
2. shift + click several files away (to select the range)
3. ctrl + t (in unstaged pane) / ctrl + u (in staged pane) only does the
   action on the first selected file (step 1)

[PhilipOakley]

That (only a single file from those selected being transfered) appears to be the same action I see on my Ubuntu box. Maybe a tcl change is part of the issue, dunno. I also remember another comment about a similar issue moderately recently (#572) - No, it was about a slightly different issue <quote> I have git-gui version 0.21.GITGUI git version 2.11.0.windows.1 Tcl/Tk version 8.6.6 My workflow is this in either the unstaged or staged window panes: 1.. click file 2.. shift + click several files away (to select the range) 3.. ctrl + t (in unstaged pane) / ctrl + u (in staged pane) only does the action on the first selected file in step 1

[kju]

Win 7 64b and Win 10 64b here. Latest git for windows (git gui 0.21/git 2.11.0.windows.1).

As far as I can tell this got broken with the most recent update of git for windows.

For now I use git gui the shortcut ctrl+I to add all, and unstage the undesired, or use git bash with git add *.ext (or more specific) to add the desired ones.

[zosrothko]

The latest version that works well displayed below

[PhilipOakley]

Jut cloned the git-gui repo as per the man page git clone http://repo.or.cz/r/git-gui.git.

http://repo.or.cz/git-gui.git/commit/088ad75dc279614849f92e5ae0a2b579b26719eb

Author: Pat Thoyts <patthoyts@users.sourceforge.net>  2016-10-01 22:04:39
   Allow keyboard control to work in the staging widgets.
   
   Keyboard focus was restricted to the commit message widget and users were
   forced to use the mouse to select files in the workdir widget and only then
   could use a key combination to stage the file.
   It is now possible to use key navigation (Ctrl-Tab, arrow keys and Ctrl-T
   or Ctrl-U) to stage and unstage files.
   Suggested by @koppor in git-for-window/git issue #859
   
   Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

This one has a look of being relevant and in the right time frame.

[PhilipOakley]

git-for-window/git issue #859 was referenced in that commit message, and lo and behold
#859 (comment)

However, Ctrl + T does not work on multiple entries anymore. Think, I have to submit another issue... 🎱

[redmanmale]

Same broken behaviour for the Staged Changes to unstage them (ctrl-u).

[koppor]

I did not submit an issue for Ctrl + T yet. May I do it here?

git-gui version 0.21.GITGUI
git version 2.11.1.windows.1
Tcl/Tk version 8.6.6

[daniel-da]

Hi,
I have this issue for a while on windows.
A workaroud I used to fix this is to edit the file: /mingw64/libexec/git-core/git-gui.tcl
and replace the lines starting from 3855

bind .   <$M1B-Key-t> { toggle_or_diff toggle %W }
bind .   <$M1B-Key-T> { toggle_or_diff toggle %W }
bind .   <$M1B-Key-u> { toggle_or_diff toggle %W }
bind .   <$M1B-Key-U> { toggle_or_diff toggle %W }

by

bind .   <$M1B-Key-t> do_add_selection
bind .   <$M1B-Key-T> do_add_selection
bind .   <$M1B-Key-u> do_unstage_selection
bind .   <$M1B-Key-U> do_unstage_selection

not sure about all sides effects of this change but it works for me :)

[PhilipOakley]

----- Original Message ----- From: daniel-da To: git-for-windows/git Cc: Philip Oakley ; Comment Sent: Wednesday, May 10, 2017 12:29 PM Subject: Re: [git-for-windows/git] critical: git-gui for Windows: multiple selections in the unstaged change panel not honored (#1012) Hi, I have this issue for a while on windows. A workaroud I used to fix this is to edit the file: /mingw64/libexec/git-core/git-gui.tcl and replace the lines starting from 3855 bind . <$M1B-Key-t> { toggle_or_diff toggle %W } bind . <$M1B-Key-T> { toggle_or_diff toggle %W } bind . <$M1B-Key-u> { toggle_or_diff toggle %W } bind . <$M1B-Key-U> { toggle_or_diff toggle %W } by bind . <$M1B-Key-t> do_add_selection bind . <$M1B-Key-T> do_add_selection bind . <$M1B-Key-u> do_unstage_selection bind . <$M1B-Key-U> do_unstage_selection not sure about all sides effects of this change but it works for me :)

…

-- My only thought was whether the { } bracketting should be still present? That is, I know those squiggly brackets mean something with regard to the point of evaluation/interpretation but I can't remember... Simailarly I'd then be wondering what the %W parameter was hoping to do and if it (or something similar) may be required if the functions were bound somewhere else. A useful find none the less. A nice bit of low hanging fruit for a fixup patch that callates the issue text into a commit messsage.... -- Philip

[dscho]

@PhilipOakley did you know that your replies are not visible in GitHub's UI unless one clicks the ... at the bottom? Highly confusing. Also, the mail headers are a bit distracting...

[PhilipOakley]

@PhilipOakley did you know that your replies are not visible in GitHub's UI unless one clicks the ... at the bottom? Highly confusing. Also, the mail headers are a bit distracting...

Yeah, the round trip interfacing is not ideal. I have difficulty because of the MS style 'top post reply' to the messages, and I can't seem to get a clean method for replying to the emails in my old email client.

Not sure if there are any better Github settings for how they send emails, or more info on how they parse emails (so when I bottom post my text doesn't get hidden below a three dots!).

Even when one does a copy paste in the web interface the formatting doesn't always come across.

[dscho]

My only thought was whether the { } bracketting should be still present? That is, I know those squiggly brackets mean something with regard to the point of evaluation/interpretation but I can't remember... Simailarly I'd then be wondering what the %W parameter was hoping to do and if it (or something similar) may be required if the functions were bound somewhere else.

The bracketing is necessary only when passing options such as %W.

As to the change, I think it is a good start of an investigation, for sure.

It is not a complete solution, obviously, as part of the Ctrl+T functionality is to unstage files when the focus is on the lower left list. Quite naturally, the do_add_selection function wants to only stage the files.

[colthreepv]

Please update this issue when a git-for-windows version with this fix is released, I'm (and presumably others) keeping their git version hold back for this painful Issue

[dscho]

To be quite honest, the patch is really a patch, i.e. it is not really a fix. The entire toggle_or_diff function would need some tender loving care, but it is quite obvious by now that those who need Git GUI fixes are pretty willing to bank on others to provide those fixes, rather than go and learn Tcl/Tk and make those fixes and open Pull Requests. So just a patch is whatcha get.

[dscho]

Please update this issue when a git-for-windows version with this fix is released, I'm (and presumably others) are keeping their git version hold back for this painful Issue

Thanks for asking me to do even more.

Do you think it really, really unreasonable for you to keep an eye out and update this ticket? Do I really have to do all of this by myself?

[colthreepv]

Sorry.. this was not aimed directly towards you, it was meant to send a notifications to subscribers

I am sure everybody in this Issue appreciate what you are doing, as you mentioned not many programmers are fluent with Tcl/Tk on github, and this is a really key piece of software

[dscho]

@colthreepv can you test the newest snapshot from https://wingit.blob.core.windows.net/files/index.html?

[colthreepv]

Multi stage/unstage on git-gui works for me with that snapshot 👍

$ git --version --build-options
git version 2.13.0.windows.1.17.g759b4f1c8e
built from commit: 759b4f1c8ed03e6e9cdfc028b47235539f1eadb0
sizeof-long: 4
machine: x86_64

[jrn]

Sent upstream: https://public-inbox.org/git/20171201234013.GD18220@aiede.mtv.corp.google.com/