Re: A project-files implementation for Git projects

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Tue, 17 Sep 2019 13:46:19 +0300
> 
> 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).

So you are going to convert the likes of .gitignore to a long list of
'find's -name arguments?  Instead of just using the tools that can do
this at a flip of a command-line argument?  Why?

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

That's a separate topic, IMO, but IME (which is admittedly thin) any
"project" kind of feature requires the user to register the files
somehow, before the file appears in the tree shown by the project's
UI.

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

That's not exactly what Tassilo said, and "bzr help ls" is just a few
keystrokes away of each one of us.

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

Where there's no VCS back-end, 'find' will have to do, and if it's
slow, there's not much we can do about it.

> And the filenotify-based cache would do one job.

IME, filenotify doesn't scale well, so I won't recommend it for
non-toy projects in this context.

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

I think you are wrong here.  It is 'find' that needs to be coerced to
do a job that is not really its prime, and a project's view is in most
cases almost exactly that of the VCS used for the project.  The
difference is just-now added files that were not yet registered, and
how many of these can there be?