fix #8106:fix open deleted file in git scm errors

[datou0412]

Signed-off-by: 二凢 [email protected]

What it does

Fixes: #8106

There is a bug when try to open deleted files in git scm, it causes errors and can not open anything.

For more detail, view the ISSUE #8106

How to test

1. Delete any file
2. Open git scm view
3. Click the deleted file in CHANGES or STAGED CHANGES

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[akosyakov]

@datou0412 Could you update the PR description please?

[lmcbout]

Open Deleted file from SCM tree in git is only available if I click on the file name to open. If I select the "Open File" button on the SCM entry, then the error is still present and the file do NOT open in the editor

[datou0412]

Open Deleted file from SCM tree in git is only available if I click on the file name to open. If I select the "Open File" button on the SCM entry, then the error is still present and the file do NOT open in the editor

yep, its another bug. I will try to fix it

[akosyakov]

@lmcbout could you try again please

[westbury]

The 'Open File' action always opens the file as it exists in the working tree. IMO, the bug is that the 'Open File' action should not be there for a deleted file, since it does not exist and cannot be opened. So remove from both the context menu and the inline action.

Double-clicking (or single-clicking depending on preferences) opens the diff. The diff for a deleted file should just show the contents that were deleted. This is technically a diff, even though one just sees one version of the file. The file contents should not be modifiable, and a diff URL should be used to open it, with (HEAD) or (Index) showing in the title.

VS-Code, interestingly enough, has exactly the same bug. 'Open File' is there both in the context menu and inline action but it does nothing. Although we can't easily fix this when using the Git builtin (which I have not tested but I assume also does nothing), we can fix this in the Theia's git package.

[westbury]

I don't think this code is complete. Consider what happens if you modify a file, stage the file, then delete the file. You should see the file with 'M' status in the staged section and with a 'D' status in the unstaged section. (If one actually tries this out then you will see an incorrect 'M' in the unstaged section. That is because of this bug #7789). If you click anything in the unstaged section then you should see the diff between the staged and the unstaged. That means if you click on the deleted file in the unstaged section then you should see the contents of the file in the index, not the contents of the file in HEAD.

Until #7789 is fixed you won't be able to test all the cases here. So on that basis I would be happy with the changes currently in git-scm-provider with a TODO that more work is needed when #7789 is fixed. I think the suggestion will be correct in all cases, but I can't test it without fixing 7789.

Suggested change

	if (change.status === GitFileStatus.Deleted) {
	return changeUri.withScheme(GIT_RESOURCE_SCHEME).withQuery('HEAD');
	}
	if (change.status === GitFileStatus.Deleted) {
	if (change.staged) {
	return changeUri.withScheme(GIT_RESOURCE_SCHEME).withQuery('HEAD');
	} else {
	return changeUri.withScheme(GIT_RESOURCE_SCHEME);
	}
	}

[westbury]

If I select the "Open File" button on the SCM entry, then the error is still present and the file do NOT open in the editor

@lmcbout @akosyakov As I commented, I don't think we should be able to open a file that has been deleted. "Open File" opens what is in the file system. We should remove "Open File" for files that have been deleted but that is a different issue. Are you okay if we leave the code in git-contribution unchanged in this PR? So we just have the fix in git-scm-provider?

@datou0412 Thanks for making the code changes and adding the TODO. There should be an explanation following the TODO, so others know that the TODO is to test the code. However, on further thought, it is probably better just to update #7789 to make sure this gets tested. So if you want to remove the TODO that is fine too. I just didn't want the testing of this code to get missed.

[akosyakov]

@akosyakov it is fine with me

[lmcbout]

I also noticed than the "Open File" does nothing in VSCODE. It is fine with me as well. We can always "Discard Changes" for a deleted file to bring it back to the workspace. So this PR solves what it is supposed to do

[westbury]

@datou0412 so we can merge this if you 1) revert the changes in git-contribution and 2) either add a description after the TODO or perhaps better just remove the TODO. Sorry, I know this takes the commit almost back to where you started.