Open armandas opened 2 years ago
Does it help to add --wait
to the command arguments?
@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.
@bpasero did you cover this case when you added the CLI option?
There is no way to return an exit code from --wait
that transports an error code currently.
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.
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 totrue
. 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.
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.
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.
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.
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:
code --disable-extensions -m --merge LOCAL.cpp REMOTE.cpp BASE.cpp OUTPUT.cpp