microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.38k stars 29.32k forks source link

Allow to return an exit code from `--wait` invocations #157961

Open armandas opened 2 years ago

armandas commented 2 years ago

I'm using Sourcetree as a git GUI and tried to set-up vscode as a three-way merge tool. Sourcetree expects that the tool will return a 0 on merge success and some error code on failure/abort. However, vscode returns 0 almost immediately, causing Sourcetree to delete the merge files.

Does this issue occur when all extensions are disabled?: Yes

Steps to Reproduce:

  1. Run the command for the three-way diff: code --disable-extensions -m --merge LOCAL.cpp REMOTE.cpp BASE.cpp OUTPUT.cpp
  2. Observe that the command returns after the window is launched.
gjsjohnmurray commented 2 years ago

Does it help to add --wait to the command arguments?

armandas commented 2 years ago

@gjsjohnmurray Thanks for the suggestion!

It does help partially. The command now returns when the file is closed.

However, if I close the file without resolving the conflicts (e.g. by clicking the "Discard Merge Changes" button), the editor still exits with code 0 and Sourcetree thinks the conflicts have been resolved.

gjsjohnmurray commented 2 years ago

@bpasero did you cover this case when you added the CLI option?

bpasero commented 2 years ago

There is no way to return an exit code from --wait that transports an error code currently.

https://github.com/microsoft/vscode/blob/eebdf8174b087979ae6af103f6f2e2f6f9062056/src/vs/code/node/cli.ts#L470-L472

Git command line in that case seems to ask if all conflicts have been resolved and does not just continue. I would also think that the presence of Git conflict markers is a good hint whether conflicts have been resolved or not.

yume-chan commented 2 years ago

From https://www.git-scm.com/docs/git-mergetool

If the custom merge tool correctly indicates the success of a merge resolution with its exit code, then the configuration variable mergetool.<tool>.trustExitCode can be set to true. Otherwise, git mergetool will prompt the user to indicate the success of the resolution after the custom tool has exited.

mergetool.<tool>.trustExitCode

For a custom merge command, specify whether the exit code of the merge command can be used to determine whether the merge was successful. If this is not set to true then the merge target file timestamp is checked and the merge assumed to have been successful if the file has been updated, otherwise the user is prompted to indicate the success of the merge.

Looks like update the file and exit with code 0, while leaving conflicts in output file may cause issues.

bpasero commented 2 years ago

We show a big dialog to the user if the user wants to close the merge editor without resolving the conflicts, so it is less likely to happen, but I agree that --wait should have support to transport an exit code back to the calling process.

Enyium commented 1 year ago

if I close the file without resolving the conflicts (e.g. by clicking the "Discard Merge Changes" button), the editor still exits with code 0 and Sourcetree thinks the conflicts have been resolved.

This is also a problem for me with TortoiseGit. I configured VS Code with --wait as the merge tool, and TortoiseGit has a checkbox "Trust the exitcode of the external merge tool for auto resolving". But this currently doesn't work. Checking it always marks conflicts as resolved.

sylann commented 1 year ago

I also have a problem when running git rebase -i ... from a terminal.

The rebase immediately succeeds and vscode fails to open git-rebase-todo (because it's already gone). The related documentation is either out of date or I have a specific problem?

The only way that works for sure is to use the default editor and then go open .git/rebase-merge/git-rebase-todo in vscode manually 😕.

EDIT: Maybe rebase is not supposed to be managed in vscode. But at the very least, using core.editor = code (or core.editor = code --wait) should not break the normal behaviour of git rebase.

Also another strange bug occurs after messing with these configurations, if I try to open the git-rebase-todo file manually, vscode fails to open it and shows a warning modal:

Title: Unable to open 'git-rebase-todo' Description: Unable to read file '/.git/rebase-merge/git-rebase-todo' (Error: Unable to resolve nonexistent file '/.git/rebase-merge/git-rebase-todo')

Even though the file exists and I can open it with other editors (while editing it in vim). Only vscode fails to open it.