Steps to Reproduce:
Good path:
git rebase or git cherry-pick which contains conflicts.--continue flag. A new window is open and an editor is created for you to update the commit message

Close the window, the command is finished properly
bad one:

Does this issue occur when all extensions are disabled?: Yes/No
@rebornix I cannot reproduce:

Can you setup the git handler to execute code out of sources to debug further?
@Tyriar any ideas?
@rebornix did you configure the git editor to use --wait?
I showed it to @Tyriar and my git config uses --wait. Will debug with Daniel about this.
I tried code-insiders.cmd --wait ./Documents/dev/Microsoft/vscode/package.json and it released just fine for me on Windows after closing the tab.
Came here from #60294. I solved the problem by changing git config core.editor from
'C:\Users\Phil\AppData\Local\Programs\Microsoft VS Code\Code.exe' --wait
to
'C:\Users\Phil\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd' --wait
or simply
code --wait
This needs to be fixed by the Git installer which seems to set up Code.exe as the editor, instead of code.cmd. cc @bpasero
Found this: https://github.com/git-for-windows/git/issues/1875
Nope, it seems there's really an issue on our side, investigating:

For the particular error @joaomoreno mentioned above, when we open a vscode instance first and then run git config -e, the code throws exceptions in https://github.com/Microsoft/vscode/blob/8a6778cecc020fa438446ade9a9030b399e988ff/src/vs/platform/launch/electron-main/launchService.ts#L234-L238 . Only the cli code creates waitMarkerFile so in this code path, args.wait is true but args.waitMarkerFile is undefined. As we didn't pass in the right waitMarkerFile, we lost the ability to quit this process and it waits until the window is being closed.
Creating a new waitMarkerFile if it doesn't exist in this case can fix it. But if we close all VSCode windows, and then run git config -e, this path of code is not being executed, a proper fix may go to electron-main/main or electron-main/app but it's beyond my knowledge.
@bpasero The investigation from @rebornix is 100% correct. Why is this code in CLI and not in the main process too? IMO they should share it.
Also, can we find a better way to do this instead of using a fake --waitMarkerFilePath opt, which gets added after args get parsed?
I fixed the NPE. I will convert this to be a feature request. I never intended this to fully work with Code.exe, but if someone has energy, feel free to jump in.
One thing that always annoyed me when using Code.exe directly is the fact that once the Electron process terminates, you are never put back to the Windows prompt. Here the launching process has terminated but the prompt is not showing up again:

Thanks! Verified the NPE is fixed. We just have to hook up the right parts in the main process now.
Yeah, that is annoying, tho I think it's more of a cmd.exe issue. You can avoid it and simulate what git does by appending | rem to the command.
@bpasero Note that a lot of new users are hitting https://github.com/git-for-windows/git/issues/1875 right now. You can easily get it by (1) installing VS Code and (2) installing Git and choose VS Code as the default editor. For that reason, we probably want to get this done.
It might be a simple matter of refactoring the code out of the CLI and be able to use it from the CLI and the main process, right?
@joaomoreno please review/test https://github.com/Microsoft/vscode/commit/4252e67b35b20203d73b31252744a21fa97de193 that addresses part of this issue for the case where Code is running and you start it with --wait. As discussed, the --waitMarkerFile will now also be set very early in the launching. It will still not be very useful for the case where Code.exe is the first process that starts, because that one will never terminate.
Verified all scenarios:
| | Code.exe | bin\code.cmd |
| ------------- | ------------- | ------------- |
| Code not yet running | 馃憣 | 馃憣 |
| Code already running | 馃憣 | 馃憣 |
Build tested: https://az764295.vo.msecnd.net/insider/e34c00f63eaca1c438120d8fb37cb0c3d67e38e2/VSCode-win32-x64-1.29.0-insider.zip
It will still not be very useful for the case where Code.exe is the first process that starts, because that one will never terminate.
It is useful, since the user usually closes the tab/editor right after editing, which will shutdown Code. The only case which doesn't work is if the user opens a new file/tab before closing the original file. This is OK for now, let's just wait for that issue to pop up in the real world.
@bpasero Great job, thanks!
@joaomoreno thanks for verifying.
Most helpful comment
Came here from #60294. I solved the problem by changing
git config core.editorfrom'C:\Users\Phil\AppData\Local\Programs\Microsoft VS Code\Code.exe' --waitto
'C:\Users\Phil\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd' --waitor simply
code --wait