Error in git GUI when trying to stage files

[redmanmale]

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

Setup

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

$ git --version --build-options
git version 2.11.1.windows.1
built from commit: 1c1842bcba45569a84112ec64f72b08eb2d57c68
sizeof-long: 4
machine: x86_64

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

Win 7 x64

$ 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?

Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
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?

No.

Details

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

Bash

• 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.

Accidently stage files from empty Unstaged Changes panel (e.g. when you already added all of them) via shortcut CTRL-T.

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

Nothing. Because all files have already been staged.

• What actually happened instead?

GUI error

expected number but got ""
expected number but got ""
    while executing
"expr {int([lindex [$w tag ranges in_diff] 0])}"
    (procedure "toggle_or_diff" line 13)
    invoked from within
"toggle_or_diff toggle .vpane.files.workdir.list "
    (command bound to event)

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

Reproducible on any repository.

Maybe related with #1012.

[PhilipOakley]

Thanks for the report, complete with error message!

This suggests that it's not the linked issue, rather it is a simple error that in this case you (we) have an empty list, and the list processing functions fail at that point - probably the lindex function.

Are you able to spare a few hours to have a go at trying for a bug fix? It's fairly easy to download the SDK and then try out the gui code. (try putting curly brackets around the $w, or thereabouts, to ensure that it stays as an emty list, rather than a disappeared list; either that, or do a size check)

If you look at my recent gui fix #1014 for the various pain points I had ;-)

[redmanmale]

I haven't much experience with programming in C, but I'll have a look and try to fix this in a couple of days.

[PhilipOakley]

The git-gui code is in tcl/tk, but just as fun ;-)

picking apart and using the info in the error message is likely to be a key helper

expected number but got ""
expected number but got ""
    while executing
"expr {int([lindex [$w tag ranges in_diff] 0])}"
    (procedure "toggle_or_diff" line 13)
    invoked from within
"toggle_or_diff toggle .vpane.files.workdir.list "
    (command bound to event)

so .vpane.files.workdir.list is the parameter substitution that is passed to toggle_or_diff toggle %W, (which then I think becomes the $w parameter later)

and the error itself is possibly that [$w tag ranges in_diff] evaluates to the "", so the indexing fails, and the int() function barfs (maybe).

[dscho]

@redmanmale please have a look at dscho@080c015: insert the lines mentioned in that diff into the file in question (C:\Program Files\Git\mingw64\libexec\git-core\git) and test whether this fixes the bug you reported.

[redmanmale]

@dscho
Unfortunately I couldn't even compile git, not to mention applying some changes.
There's too much unix-smelling stuff in all that, I gave up after several evenings.

[dscho]

@redmanmale you did not dig very hard. The commit I referenced touches only git-gui.sh, which is installed as /mingw64/libexec/git-core/git-gui without compiling anything at all...

So please test (by copying).

[redmanmale]

@dscho
Just checked up your changes. Everything works fine, bug is fixed.
Thank you!

[dscho]

Thank you @redmanmale.

[redmanmale]

@dscho

Very similar bug on

$ git --version --build-options
git version 2.12.0.windows.1
built from commit: d4baef1cdfef9de62d43f9682a98ba57adc842e4
sizeof-long: 4
machine: x86_64

with different error:

can't read "file_lists(.vpane.lower.diff.body.t)": no such element in array
can't read "file_lists(.vpane.lower.diff.body.t)": no such element in array
    while executing
"llength $file_lists($w)"
    (procedure "toggle_or_diff" line 13)
    invoked from within
"toggle_or_diff toggle .vpane.lower.diff.body.t "
    (command bound to event)

Steps to reproduce:

• git init
• open GitGUI
• focus diff panel
• focus unstaged changes panel
• ctrl-t - and you got error via MessageBox

[PhilipOakley]

Hi, the error message tells us that the line llength $file_lists($w) reported an error that it could not find any actual content for the $w which defers effectively to the `file_lists(.vpane.lower.diff.body.t)' which is the attempt to read the empty pane.

Probably needs a catch of some sort in that file_listsroutine which binds to that display pane / canvas.

[redmanmale]

Could you please reopen this issue or I should create a new one?

[PhilipOakley]

What is the difference between the testing you found as 'fixed' and the current test? i.e. 'they previous testing only covered a limited case', 'the previous testing wrongly reported a success', 'the previous test was a wrong test' (one view), or ' this error is about a specifically different detail of using the ctrl-T`, etc.

Basically, if dscho's fix worked for a specific case that was described, then starting a new issue (including referencing your comment in this thread) is probably the right solution to avoid contamination. Make sure the new issue description has sufficient clarity to decide what to do, and how you/we will know when it is fixed (the closure issue).

(aside: the key debugging point was at #1014 (comment) where I was able to easily run the gui from the shell without any compilation! - just check if the routines you adjusted are in the linked GUI_LIB given in dscho's command line)

[dscho]

Basically, if dscho's fix worked for a specific case that was described, then starting a new issue (including referencing your comment in this thread) is probably the right solution to avoid contamination.

Exactly. If the original issue was fixed, this ticket should stay closed.

@redmanmale please note that there are almost 100 tickets open. Now imagine that you tried to get them all addressed. Now imagine that I added a different bug report in the middle of one ticket. So now you have to keep in mind that this ticket is actually two tickets. Confusing, right? Especially when you have all those other tickets being handled the exact same way: more issues reported to the same ticket, so that the maintainer has to read the entire ticket just to find out whether there is still anything to be addressed.

That is why I ask for the courtesy of being a little disciplined and keep to the rule: 1 ticket = 1 issue.

So if the original issue is not addressed, please holler here.

[redmanmale]

@dscho
I'm totally agree with you.