gitkraken / vscode-gitlens

Supercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more
http://gitkraken.com/gitlens
Other
8.93k stars 1.27k forks source link

Compare "Working Tree" misses untracked files in "Search & Compare" view #1578

Open shoffmeister opened 3 years ago

shoffmeister commented 3 years ago

The "Search & Compare" view has the option to perform a comparison of the "Working Tree" against, e.g., main.

Alas, a comparison of "Working Tree" misses out on untracked files ("U") present in the current working tree. Staging any untracked files (adding them to the index) will make them show up in the comparison.

Now, this is not only a simple wording challenge between "Working Tree" and "Index", because already tracked files ("M" or "D") are considered for comparison from the working tree (and not the index).

Steps to Reproduce:

  1. clone any non-empty repository, e.g. vscode-gitlens
  2. cd vscode-gitlens
  3. git checkout -b showme
  4. code .
  5. switch to Search & Compare view
  6. "Compare References" -> Working Tree <-> main --> no changes - cool

Problem - untracked + unstaged files not listed:

Bonus - changes are indeed shown from the working tree, not from the index (correct behaviour)

Bonus - delete is also shown correctly

shoffmeister commented 3 years ago

Taking a quick peek at the implementation, it would seem as if getAheadFilesQuery and getBehindFilesQuery both use getDiffStatus underneath - which then uses git diff - and git diff will disregard added files (and, apparently, cannot be convinced to mix in files added in the working directory).

Perhaps it would make (more) sense to use the output of git status for preparing the view output against the working directory? After all, gitlens uses the git output only for populating the view, so:

> git status --short

MM README.md
A  missing-in-comparison.txt
 D tsconfig.json

might be fine?

EDIT: git status does not allow specifying a ref (it is relative to the index) - so that's a a no-go. Perhaps git ls-files --others -t to identify files in the working tree which are not known to the index, and then simply mix that into the (existing) comparison? After all, it is not important to get content comparison right, only to identify the set of files?