[BUG] git gui can't commit multiple files

This is a regression in git 2.11.0 (version 2.10.2 is fine).

In git-gui I select multiple files in the Unstaged Changes (using
shift+click) and press ctrl+t to stage them. Then only one files gets
staged instead of all of the selected files.
The same happens when unstaging files.

Git-cola also exhibits the same behavior. Although there I could stage
multiple files if I used a popup menu instead of the keyboard shortcut
(I'm guessing it goes through a different code path?).

Note that I tested by reverting back to 2.10.2 and verified that
everything works, so I'm quite certain that this is a regression in
git.

On Sun, Dec 04, 2016 at 05:36:46PM +0100, Timon wrote:

This is a regression in git 2.11.0 (version 2.10.2 is fine).

In git-gui I select multiple files in the Unstaged Changes (using
shift+click) and press ctrl+t to stage them. Then only one files gets
staged instead of all of the selected files.
The same happens when unstaging files.

Git-cola also exhibits the same behavior. Although there I could stage
multiple files if I used a popup menu instead of the keyboard shortcut
(I'm guessing it goes through a different code path?).

Can you elaborate a bit?

I just tested git-cola with Git 2.11 and it worked fine for me.
I selected several files and used the Ctrl+s hotkey to stage the
selected files.  They all got staged.

If you have a test repo, or reproduction recipe, I'd be curious
to try it out.
-- 
David

On 12/4/16, David Aguilar [off-list ref] wrote:

On Sun, Dec 04, 2016 at 05:36:46PM +0100, Timon wrote:

quoted

This is a regression in git 2.11.0 (version 2.10.2 is fine).

In git-gui I select multiple files in the Unstaged Changes (using
shift+click) and press ctrl+t to stage them. Then only one files gets
staged instead of all of the selected files.
The same happens when unstaging files.

Git-cola also exhibits the same behavior. Although there I could stage
multiple files if I used a popup menu instead of the keyboard shortcut
(I'm guessing it goes through a different code path?).

Can you elaborate a bit?

I just tested git-cola with Git 2.11 and it worked fine for me.
I selected several files and used the Ctrl+s hotkey to stage the
selected files.  They all got staged.

If you have a test repo, or reproduction recipe, I'd be curious
to try it out.
--
David

Can you try with git gui?
Though I guess it's probably specific to my distro or configuration.
I'm running 64bit gentoo with:
linux 4.8.12
gcc 5.4.0
glibc 2.23-r3
tk 8.6.6
gettext 0.19.8.1
openssl 1.0.2j
Not sure if that's helpful though.

Originally I had this problem in gentoo and assumed in the end it's
likely due to my specific configuration.
However recently I switched to nixos and am still experiencing it.

I've search again if I can find anything and lo and behold, it's
already fixed in the *windows* version of git-gui...

issue thread: https://github.com/git-for-windows/git/issues/1012
commit: https://github.com/git-for-windows/git/commit/1c4d4e7cbcf404c168df5537d55e9afd57f2b01b

I applied it locally to git-2.15.0 and can confirm it fixed the problem for me.
If you need any more info/help from me, or would like me to test
anything, feel free to ask.

On 12/5/16, Timon [off-list ref] wrote:

On 12/4/16, David Aguilar [off-list ref] wrote:

quoted

On Sun, Dec 04, 2016 at 05:36:46PM +0100, Timon wrote:

quoted

This is a regression in git 2.11.0 (version 2.10.2 is fine).

In git-gui I select multiple files in the Unstaged Changes (using
shift+click) and press ctrl+t to stage them. Then only one files gets
staged instead of all of the selected files.
The same happens when unstaging files.

Git-cola also exhibits the same behavior. Although there I could stage
multiple files if I used a popup menu instead of the keyboard shortcut
(I'm guessing it goes through a different code path?).

Can you elaborate a bit?

I just tested git-cola with Git 2.11 and it worked fine for me.
I selected several files and used the Ctrl+s hotkey to stage the
selected files.  They all got staged.

If you have a test repo, or reproduction recipe, I'd be curious
to try it out.
--
David

Can you try with git gui?
Though I guess it's probably specific to my distro or configuration.
I'm running 64bit gentoo with:
linux 4.8.12
gcc 5.4.0
glibc 2.23-r3
tk 8.6.6
gettext 0.19.8.1
openssl 1.0.2j
Not sure if that's helpful though.

From: Johannes Schindelin <redacted>
Subject: git-gui: allow Ctrl+T to toggle multiple paths

In the Unstaged Changes panel, selecting multiple lines (using
shift+click) and pressing ctrl+t to stage them causes one file to be
staged instead of all of the selected files.  The same also happens
when unstaging files.

This regression appears to have been introduced by gitgui-0.21.0~7^2~1
(Allow keyboard control to work in the staging widgets, 2016-10-01).

Also reported by zosrothko as a Git-for-Windows issue:
https://github.com/git-for-windows/git/issues/1012

[jn: fleshed out commit message]

Reported-by: Timon <redacted>
Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
Hi Timon,

Timon wrote:

quoted

quoted

On Sun, Dec 04, 2016 at 05:36:46PM +0100, Timon wrote:

quoted

quoted

quoted

This is a regression in git 2.11.0 (version 2.10.2 is fine).

In git-gui I select multiple files in the Unstaged Changes (using
shift+click) and press ctrl+t to stage them. Then only one files gets
staged instead of all of the selected files.
The same happens when unstaging files.

[...]

Originally I had this problem in gentoo and assumed in the end it's
likely due to my specific configuration.
However recently I switched to nixos and am still experiencing it.

I've search again if I can find anything and lo and behold, it's
already fixed in the *windows* version of git-gui...

issue thread: https://github.com/git-for-windows/git/issues/1012
commit: https://github.com/git-for-windows/git/commit/1c4d4e7cbcf404c168df5537d55e9afd57f2b01b

I applied it locally to git-2.15.0 and can confirm it fixed the problem for me.
If you need any more info/help from me, or would like me to test
anything, feel free to ask.

Thanks for this pointer.  I'm including the patch here so the project
can consider applying it (it doesn't appear to have been sent upstream
before).  I have not tested it or verified the claim it makes about
what change introduced this regression --- if you're able to help with
that, that would be welcome.

Thanks,
Jonathan

 git-gui.sh | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/git-gui.sh b/git-gui.sh
index ed24aa9..ef98fc2 100755
--- a/git-gui.sh
+++ b/git-gui.sh

@@ -2501,6 +2501,19 @@ proc toggle_or_diff {mode w args} {
 		set pos [split [$w index @$x,$y] .]
 		foreach {lno col} $pos break
 	} else {
+		if {$mode eq "toggle"} {
+			if {$w eq $ui_workdir} {
+				do_add_selection
+				set last_clicked {}
+				return
+			}
+			if {$w eq $ui_index} {
+				do_unstage_selection
+				set last_clicked {}
+				return
+			}
+		}
+
 		if {$last_clicked ne {}} {
 			set lno [lindex $last_clicked 1]
 		} else {

-- 
2.15.0.531.g2ccb3012c9

Jonathan Nieder wrote:

From: Johannes Schindelin <redacted>
Subject: git-gui: allow Ctrl+T to toggle multiple paths

In the Unstaged Changes panel, selecting multiple lines (using
shift+click) and pressing ctrl+t to stage them causes one file to be
staged instead of all of the selected files.  The same also happens
when unstaging files.

This regression appears to have been introduced by gitgui-0.21.0~7^2~1
(Allow keyboard control to work in the staging widgets, 2016-10-01).

Also reported by zosrothko as a Git-for-Windows issue:
https://github.com/git-for-windows/git/issues/1012

[jn: fleshed out commit message]

Reported-by: Timon <redacted>
Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Jonathan Nieder <redacted>

Gah, this should say:

Signed-off-by; Jonathan Nieder [off-list ref]

[...]

quoted

I applied it locally to git-2.15.0 and can confirm it fixed the problem for me.
If you need any more info/help from me, or would like me to test
anything, feel free to ask.

Thanks for this pointer.  I'm including the patch here so the project
can consider applying it (it doesn't appear to have been sent upstream
before).  I have not tested it or verified the claim it makes about
what change introduced this regression --- if you're able to help with
that, that would be welcome.

Can you bisect?  That is:

 git clone git://repo.or.cz/git-gui
 cd git-gui
 git bisect start
 git bisect good gitgui-0.20.0
 git bisect bad gitgui-0.21.0

Then cut to the chase:

 git checkout gitgui-0.21.0~7^2~1
 ... test test test ...
 git bisect (good|bad)

 git checkout gitgui-0.21.0~7^2~1^
 ... test test test ...
 git bisect (good|bad)

and follow the instructions if it suggests testing additional versions.

Then I'll be happy to re-send the patch with the results from your
testing.

Thanks again,
Jonathan

On 12/2/17, Jonathan Nieder [off-list ref] wrote:

Jonathan Nieder wrote:

quoted

From: Johannes Schindelin <redacted>
Subject: git-gui: allow Ctrl+T to toggle multiple paths

In the Unstaged Changes panel, selecting multiple lines (using
shift+click) and pressing ctrl+t to stage them causes one file to be
staged instead of all of the selected files.  The same also happens
when unstaging files.

This regression appears to have been introduced by gitgui-0.21.0~7^2~1
(Allow keyboard control to work in the staging widgets, 2016-10-01).

Also reported by zosrothko as a Git-for-Windows issue:
https://github.com/git-for-windows/git/issues/1012

[jn: fleshed out commit message]

Reported-by: Timon <redacted>
Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Jonathan Nieder <redacted>

Gah, this should say:

Signed-off-by; Jonathan Nieder [off-list ref]

[...]

quoted

quoted

I applied it locally to git-2.15.0 and can confirm it fixed the problem
for me.
If you need any more info/help from me, or would like me to test
anything, feel free to ask.

Thanks for this pointer.  I'm including the patch here so the project
can consider applying it (it doesn't appear to have been sent upstream
before).  I have not tested it or verified the claim it makes about
what change introduced this regression --- if you're able to help with
that, that would be welcome.

Can you bisect?  That is:

 git clone git://repo.or.cz/git-gui
 cd git-gui
 git bisect start
 git bisect good gitgui-0.20.0
 git bisect bad gitgui-0.21.0

Then cut to the chase:

 git checkout gitgui-0.21.0~7^2~1
 ... test test test ...
 git bisect (good|bad)

 git checkout gitgui-0.21.0~7^2~1^
 ... test test test ...
 git bisect (good|bad)

and follow the instructions if it suggests testing additional versions.

Then I'll be happy to re-send the patch with the results from your
testing.

Thanks again,
Jonathan

Did the testing and it went smoothly with the outcome:

088ad75dc279614849f92e5ae0a2b579b26719eb is the first bad commit
commit 088ad75dc279614849f92e5ae0a2b579b26719eb
Author: Pat Thoyts [off-list ref]
Date:   Sat Oct 1 22:04:39 2016 +0100

    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 [off-list ref]

:100755 100755 11048c7a0e94f598b168de98d18fda9aea420c7d
ec1cc43e8f73acd3d52047ece4dfab5edeb6ffb4 M	git-gui.sh