Re: A project-files implementation for Git projects

[Dmitry Gutov]

On 16.09.2019 18:25, Eli Zaretskii wrote:

> > Should we sacrifice some correctness for speed?
>
> No, but it was never my intent to say otherwise.  What is "correct"
> here?  E.g., 'find' will find _all_ the files, including the ignored
> one -- is that "correct"?

'find' can handle an arbitrary list of ignores, including whitelisting 
entries (a feature which I've yet to add, but still).

Not every file that's registered in a VCS should be seen as part of the 
project, and some of the unregistered (and gitignore-d) still should be 
(e.g. config files that are created by every developer individually but 
still should be editable by them through Emacs and project-find-file).

> > If backends other than Git (and maybe Hg) can't return untracked
> > files
>
> Which backend cannot do that?  Bzr can (you just need to call it
> twice), and the other two also can.  So I think we have no problem
> here.

Tassilo said that Bzr can't, I haven't checked. There was also talk of 
SVN, so "the other two" might mean "the other three".

> > We could make up some performance using filenotify and caching, so that
> > 'find', though slower, would at least be called infrequently.
>
> That's over-engineering, I think.

Really? Consider: we have to maintain the find-based approach anyway 
since not everyone uses Git/Hg/Bzr.

And the filenotify-based cache would do one job. Conceptually, at least, 
it should be simpler than coercing several VC systems into doing the job 
of 'find' with ignore/whitelist entries not exactly matching VCS's view 
of the repository.