Re: A project-files implementation for Git projects

[Dmitry Gutov]

On 14.09.2019 19:26, Tassilo Horn wrote:

> As Eli said, just stat find is faster than, e.g., "bzr ls" on my
> GNU/Linux system doesn't mean much.  One benefit is that if you have a
> bzr project, you'll have bzr installed.  That doesn't need to be the
> case for find at least on Windows systems.

Makes sense. If 'find' is not available, defaulting to Bzr might be an 
option. Although I'm concerned that if it misses some of the files, it 
might be better to tell the user to install 'find'.

> "bzr ls" has an --unknown flag which should list unknown files and an
> --ignored flag to list ignored files, but in my version it then just
> lists nothing when I specify either one.

*shrug* I wouldn't spend too much time on this particular VCS.

> "hg files" doesn't seem to have a way to list untracked files.  Same for
> subversion.

I've only looked into Mercurial so far, and 'hg status -u' seems to do 
the trick. Depending on performance, you could call 'hg status -c -u', 
or augment the output of 'hg files' with a call to 'hg status -u'.

> If you have an interface in mind (i.e., list-files all arguments and
> their meaning), I can try and check how far we can get.

I think it's either

  (list-files include-untracked extra-ignores whitelist)

or

  (list-files pathspecs include-untracked all-ignores)

where pathspecs defaults to nil meaning "all files" and all-ignores 
defaults to the current contents of .gitignore. It could also be 
interpreted as a file name, but I'm guessing most backends would have a 
hard time supporting this usage.

In the latter case project-files's implementation would contain some 
backend-specific code, e.g. to translate additional ignores into 
pathspec values, so that they also apply to tracked files.

Overall, I'm not 100% sure that we should use VC backend action here 
because it seems like we'll be fighting an impedance mismatch between 
what Git thinks its files are and what we want to see in the list of 
project files. We probably want to use Git because it's fast and 
flexible, but other VCSes are going to be less helpful. So if I were 
writing this myself I'd create a "fast path" for Git repos, and delegate 
to 'find' otherwise.