Support `git diftool -d`, AKA Git directory diff

[segevfiner]

When VS Code is set as the difftool for Git, make it work nicely with git difftool -d, AKA a directory diff. VS Code doesn't know how to handle that scenario well ATM.

[gabeklavans]

I would love the ability to use vscode for this

[dpward]

This is the same request as #6898, #48437, #63548 which were closed without action. These had a combined 60 votes.

@joaomoreno It's not clear to me that other commenters conveyed why this functionality is part of the Git workflow. Do you need more context?

This is about viewing the difference before/after a sequence of commits, when the changes span multiple files. It is especially useful during code refactoring. It shows which files have changed, then allows the developer to select files for side-by-side viewing of their changes. This way, it is possible to see that changes in two (or more) different files offset each other, i.e., when code is relocated. If the diff is performed against the working tree (rather than between two commits), edits can be made in this view.

[saierd]

I think now that the multi-diff editor exists, this feature could potentially be implemented by treating a directory given to --diff like a list of files for the multi-diff editor.

This would be straightforward for files which exist in both directories. For a complete implementation of a directory diff one would obviously need to handle moved files as well, which is trickier. Maybe ignoring moves and just showing a diff to an empty file in that case would be enough for a start.

From looking around the code a bit (I am not familiar with the code base), it seems like this feature could go somewhere around here. When pathsToEditors discovers that the paths are directories, read the list of files in those directories and give them to openResources, which can then create a IResourceMultiDiffEditorInput for opening the multi-diff editor.

Would such an implementation be acceptable as a contribution?

[tyleo]

I agree with @dpward's opinion that closing all of the existing issues is overzealous, though I could see some being closed as duplicates.

git difftool --dir-diff {lhs} {rhs} is the most common way I use git difftool these days. I've eagerly awaited this functionality in VSCode. It's a delightful feature in Araxis Merge and the only reason I prefer it over VSCode for diff.

I also agree with @saierd's recommendation to support this with the multi diff editor. It looks like a great solution and would hit the bar for replacing competing tools in my workflow.

@saierd, I'm curious if you tried implementing your suggestion. While it may not be a goal or golden path for the VSCode team, it looks like the normal course of iteration may have sleepwalked close to a viable solution to this request. I'm hopeful that you've discovered a path forward that folks can agree on.

I don't have experience with VSCode development but I have JS/TS/UI experience and I'm willing to provide development bandwidth here if there is anything I can do to help move this along.