git rebase -i and squash fails with gpgsign turned on.

[333fred]

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

  • This is related to #871, but related to squashing during a rebase.
    

    Setup

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

I'm using 2.10.1, 64-bit. This scenario works previous to 2.10.

$ git --version --build-options
git version 2.10.1.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?

Windows 10, 64-bit. I'm using Insiders slow on this machine, but I'm using the anniversary update on others that display this issue.

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.14931]

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

Default options.

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled

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

I sign all of my commits, and I've set commit.gpgsign to true.

Details

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

  I've tried this from powershell and Git 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.

I'm attempting to squash some commits by using interactive rebase. Simply go to any repo and attempt to run git rebase -i -S HEAD^^^^, and pick some commits to squash. The issue will occur when you get to the commits chosen to squash.

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

I expected the rebase to work successfully.

• What actually happened instead?

When git gets to the commit being squashed, the following error will occur:

gpg: cannot open tty `no tty': No such file or directory
error: gpg failed to sign the data
fatal: failed to write commit object
Could not apply 49b8c4b... Fixes the gradle dependencies for building (#269)

The rebase works when not attempting to squash; if I run git rebase -i otherbranch that has no conflicts and I don't attempt to squash anything, it works as expected, including prompting me for my GPG key.

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

Every repo I've tried exhibits this. No specific repo should be necessary.

[dscho]

We saw a very similar breakage with git commit -S recently. Can you verify that that command works correctly (or that it shows the very same problem)?

[333fred]

Yep, #871. Signing seems to work everywhere else I've tried. It only seems to fail when squashing commits.

[dscho]

FWIW I decided to work on higher priority issues because my take is that most users who need to GPG sign commits will not want to type the same passphrase over and over and over again, so they won't be bitten by that "no tty" bug.

It is still a bug, of course.

[AraHaan]

I am about to look in the git code to see if I can make git be able to load up the gpg sign password from global user config and use that when configured instead of asking users for the sign keys all the time. It should then make it easier to write / rebase commits to make unsigned commits signed when needed. Hopefully I can find the right place to do such and then test it out. But yeah that is my plan and name the config entry signingkeypassword.

With that entry it would also fix the fact that GitHub Desktop (which also uses git for windows) would not work wihen gpg signing commits because of the fact it does not even allow you to type in the gpg password making creating commits fail when you force git to always sign everything.

[333fred]

@AraHaan just to be sure I'm understanding, you're wanting to create a new config entry and have people store their gpg passwords in plaintext? If so, this is a _very_ bad idea. Many people (including me) keep their gitconfigs and other dotfiles in a git repo that lives on github, so if I committed my password it would be publicly available for the world to see. That aside from all the other problems of leaving a password that you use to verify your identity sitting in plaintext on your computer. Just use a gpg agent, as @dscho implied, and this issue shouldn't affect you.

[AraHaan]

I am saying in a global git config that would exist on a particular target machine(s) only that a particular user (you) use. So yeah it is a good idea. I would take no responsibility for idiots who commits their passwords on github. And here is also my reasoning. What if I want to set up some sort of API that would commit changes to things when requested with a certain diff and repository name to make the commit and stuff for me provided a commit name and message. That would make all my attempts a lot easier as well when I would enforce gpg signing on all commits it makes. And yes I plan to have git be able to read encrypted gpg passwords not plain text. However it could work in plain text when on an certain machine.

[dscho]

In the meantime, we switched to a GNU Privacy Guard version that comes with a GUI dialog for the password. So once again, it seems that procrastination worked, although probably not in a very timely manner.