Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
armandas opened this issue Aug 11, 2022 · 8 comments
Open

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

armandas opened this issue Aug 11, 2022 · 8 comments
Labels
feature-request Request for new features or functionality keep Issues we should not close as out of scope workbench-cli VS Code Command line issues workbench-os-integration Native OS integration issues
Milestone

Comments

@armandas
Copy link

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

  • VS Code Version: 1.70.1
  • OS Version: Windows 10

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
Copy link
Contributor

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

@armandas
Copy link
Author

@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
Copy link
Contributor

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

@bpasero
Copy link
Member

bpasero commented Aug 12, 2022

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

function eventuallyExit(code: number): void {
setTimeout(() => process.exit(code), 0);
}

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
Copy link
Contributor

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
Copy link
Member

bpasero commented Aug 15, 2022

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.

@bpasero bpasero added feature-request Request for new features or functionality workbench-os-integration Native OS integration issues workbench-cli VS Code Command line issues labels Aug 15, 2022
@bpasero bpasero added this to the Backlog milestone Aug 15, 2022
@bpasero bpasero changed the title Three-way merge command returns with exit status 0 immediately Allow to return an exit code from --wait invocations Aug 15, 2022
@bpasero bpasero added the keep Issues we should not close as out of scope label Dec 8, 2022
@Enyium
Copy link

Enyium commented Feb 9, 2023

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
Copy link

sylann commented Mar 28, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality keep Issues we should not close as out of scope workbench-cli VS Code Command line issues workbench-os-integration Native OS integration issues
Projects
None yet
Development

No branches or pull requests

8 participants