gitk does not work anymore during `git add -p`

[bogdanb]

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.25.0.windows.1
cpu: x86_64
built from commit: 7c71c859c97853ed057da5cbab12f3c13b5554df
sizeof-long: 4
sizeof-size_t: 8

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

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17763.914]

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

$ cat /etc/install-options.txt

Editor Option: CustomEditor
Custom Editor Path: "c:\Program Files (x86)\Geany\bin\Geany.exe" -i
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

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

I think I remember seeing something about a (possibly experimental) C re-implementation of git add, which is what I suspect is responsible for this. I’m pretty sure I enabled the option, but I don’t see anything related in the install options above.

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.

> gitk &
> git add -p

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

Assuming there are any changes in the repository, i.e. that git add doesn’t exit immediately, I would expect to be able to use the gitk to look at the repository history, including the contents of existing commits, the contents of the index, and any local changes that are not yet checked into the index.

Note that this used to work until recently (around December 2019). I’ve been using it a lot; for example, when picking changes it’s often useful to look at more context than just git add -p provides, or to run git blame on a line (via the right-click menu in gitk).

• What actually happened instead?

While git add -p is still running (i.e., displaying a prompt and waiting for a user decision), gitk does not display any commit content other than what was initially selected.

If you click on a commit (or the special index/local changes entries), it shows the metadata (parent, hash, author, description), but it does not show the commit changes/tree. (The areas where these would be shown are just blank.) If you stop git add, the content of the selected commit appears in gitk a moment later.

I imagine what happens is that the git add command is holding some sort of lock while waiting for user input that it didn’t use to hold a couple months ago. I’m not sure if the correct fix is for gitk to ignore that lock, or for git add to stop holding it.

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

As far as I’m aware, it happens in any repository.

[dscho]

Are you using the (experimental) built-in git add -p?

[bogdanb]

I think I am, but I’m not sure how to check for sure. I remember a prompt about something like that during the last upgrade, and I think I enabled it, but I’m not 100% sure. I don’t really know how to toggle it by hand, either.

[dscho]

You can verify your lock theory by looking for the .git/index.lock file while running git -c add.interactive.usebuiltin=true add -p and then the same with false instead of true.

[bogdanb]

Thanks for the pointer. So I did some testing, and:

1. The bug does not happen when add.interactive.usebuiltin=false
2. The bug does happen when add.interactive.usebuiltin=true
3. Regardless of the configuration, there is no .git/index.lock file while git add -p is waiting for a decision:

$ ls -a .git/index.lock
ls: cannot access '.git/index.lock': No such file or directory

So the new (experimental) built-in git add -p does cause the issue somehow, but it’s not via the .git/index.lock file

[bogdanb]

Oh, and I just noticed something during the tests. In my description above I said that when the bug manifests it does not show anything except the commit info. Actually, it never shows a commit’s changes, but it does show the tree (the list of files touched by the commit) for those commits that I have looked at before running git add -p. I suppose it might have cached some of the data in that case.

[dscho]

@bogdanb I am a bit unsure what you're asking. So when I open gitk, then modify a file, then hit F5, I see an extra
on top. When I click on that, I see the diff in the lower left.

If I then call git add -p and stage only part of the modifications, while git add -p is running gitk won't show anything else, no matter how often I press F5. Only when I quit git add -p (after staging a couple hunks but not all) do I see this:

The really funny part for me is that this is the same behavior whether I set add.interactive.useBuiltin to true or false.

Apparently your experience differs? Could you add more details so I understand what you mean?

[dscho]

@bogdanb are you interested in this ticket at all anymore?

[bogdanb]

Still interested, but I'm on vacation right now, I'll be able to reply meaningfully in about ten days.

…

On Sun, Feb 2, 2020, 16:48 Johannes Schindelin ***@***.***> wrote: @bogdanb <https://github.com/bogdanb> are you interested in this ticket at all anymore? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2490?email_source=notifications&email_token=AABXBKE4GTFX2ZZLSSPEZMLRA3FJ5A5CNFSM4KLFXPQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRXHAI#issuecomment-581137281>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXBKEMFZRKXBFRYM4QKKLRA3FJ5ANCNFSM4KLFXPQA> .