Re: A project-files implementation for Git projects

[Dmitry Gutov <dgutov@yandex.ru>]

On 17.09.2019 16:14, Eli Zaretskii wrote:

> My point is that having to work with
> long 'find' command lines is unwieldy and inelegant.  A given VCS
> repository can have many dozens of ignored files.

I don't see how the length of the command line is an issue. The user 
won't see it.

And anyway, as we've established, the find-based solution will have to 
be there anyway, at least for some uses. So there's no use arguing about 
its awkwardness: the complexity coming with it will have to be there anyway.

>> Second, like I said, using Git for this purpose seems easy enough.
>> Others, less so.
> 
> I don't see how you arrived to the last conclusion.  AFAIU, Tassilo
> presented code to deal with others as well.

Sorry it's in the thread. Including the end of the message you were 
replying to.

>> It's not intuitive that a user has to vc-register a file before it shows
>> up in 'project-find-file'.
> 
> We already established that we will show also non-registered files, so
> this is a non-issue.

I was replying to a sentence from you where you seemed to disagree.

>>   From what I see, it doesn't allow to "unignore" certain files
>> selectively, and I'm not sure if there's a way to apply additional
>> ignores except by doing it in Lisp.
> 
> What do you mean by "unignore"?  Which VCS backend allows you to do
> that, and how?

Err, not yet.

But I'm thinking we should allow adding entries like '!/foo/bar' to 
project-vc-ignores, similar to Git's related syntax.

The find-based indexer is yet to learn to support that feature, but 
asking Git to add extra whitelist entries looks fairly easy.

> It isn't the problem of filenotify the package, it's a problem with
> the OS features it uses: inotify, knotify, etc.  They all lose events
> when there are a lot of file operations in a tree.  E.g., try using
> Auto-revert-tail mode on a log file produced by building the Boost
> library -- in the default mode, where it uses file notifications, it
> simply chokes.

Should there be a way to debounce the events, or handle this somehow? 
For instance, when too many events come, we could simply discard the 
files list cache, and force it to be rebuilt later. For this particular 
use, we don't really have to see every notification.

>> That's not the only problem. We want to change the ignores list
>> arbitrarily, or maybe just use a user-defined one. It will usually
>> correlate with the contents of gitignore/hgignore/bzrignore, but not
>> exactly. And neither Hg or Bzr seem to offer easy ways to adjust their
>> lists of ignores before output.
> 
> Then those features will be not available for hg and bzr, or we will
> tell their users that must have that to switch to 'find'.  But let's
> not bypass VC where it can do the job, because that's TRT from where I
> stand.  We should not design our implementations for the lowest
> denominator, especially when we know that a large proportion of the
> users will use Git anyway.

Yes. Like I said several messages back: "We probably want to use Git 
because it's fast and flexible, but other VCSes are going to be less 
helpful". Tassilo might prove me wrong in some instances, but it's 
definitely hard to support this feature across the range of VC backends.

So it *would* make sense to bypass VC (the API) and just use Git (and 
maybe Hg) directly when available.