[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A project-files implementation for Git projects

From: Dmitry Gutov
Subject: Re: A project-files implementation for Git projects
Date: Sun, 15 Sep 2019 21:56:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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

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)


  (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]