[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: Thu, 19 Sep 2019 18:33:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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.

reply via email to

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