"jobs" in GIT bash shell not working properly

[zzx88991]

• 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 2.9.0.windows.1

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

Windows [Version 10.0.14393]

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

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?

The git bash shell installed on my machine is based on MINGW64

Details

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

**Bash Shell **

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

webpack --progress --w --config someConfig.js
CTRL-Z
jobs
fg %1

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

I am running webpack with watch option in the shell, and CTRL-Z to let it run in background. Then typed jobs command, and it list the webpack job. As long as this job is not terminated, it should be able to be brought back

• What actually happened instead?

Waited for few seconds and typed jobs again, but this time didn't list anything while the command is running actively in the bg. And i couldn't use fg to bring it back. Also it doesn't exist in the result of ps

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

Not seems like related to repo

[dscho]

It is unfortunately correct that the Git Bash cannot exercise job control over git.exe (or for that matter, any program other than MSYS2 ones). As the process signaling of Win32 programs is so vastly different from the POSIX semantics expected by Bash's job control, I doubt that this can be fixed without an insane amount of work. I would love to be proven wrong, of course.

[doronbehar]

I've stumbled upon this issue as well. For me it's quite sever and it should be in high priority.

It so happened to me that I was in the middle of a large merge conflict reaolution of a huge file and I just wanted to run a command in the shell. When I ran fg, I couldn't return to where I stopped. All my work was lost.

IMO, even if we can't solve this issue instantly, we should set a default configuration for vimdiff that will disable c-zwhen invoked from git mergetool/difftool.

[dscho]

@doronbehar any help toward what you describe will be very welcome.

[doronbehar]

Since This project is new to me and it's quite huge, would you be kind enough and guide me please to where vim is bundled inside the repository?

[dscho]

@doronbehar certainly.

The vimdiff.exe program is part of the vim package (I found out by running pacman -Qo $(which vimdiff.exe) in Git for Windows' SDK).

I have no idea where vimdiff in particular is configured, but I think the central vim configuration is in /etc/vimrc. Maybe you find a way how to modify the vimrc so that Ctrl+Z is intercepted and turned into a noop?

The /etc/vimrc file is actually owned by the git-extra package: https://github.com/git-for-windows/build-extra/tree/master/git-extra

So a PR to https://github.com/git-for-windows/build-extra changing the vimrc file in git-extra/ should then fix it.

[doronbehar]

I've been thinking a lot about this issue and I think it's related to another issue Linux users experience as well. I can generalize the problem by asserting there is no way for text editors in general to know whether or not they were invoked by git or not. It could be an option to just add something like this to vimrc:

" Explaining comment
nnoremap <C-Z> <NOP>

But we don't want to disable <C-z> when it is invoked in a normal vim session, we should do it only when it is invoked from git. I tried to make a quick Google search and stumbled upon this question. But IMO, there should be made a PR to original git and git-for-windows that will notify all text editors that they were invoked from a git command using an environmental variable, such as %GIT_INVOKED_TEXT_EDITOR%.

What do you think?

[doronbehar]

Added PR to build-extra.