Re: A project-files implementation for Git projects

[Dmitry Gutov <dgutov@yandex.ru>]

On 23.09.2019 10:42, Tassilo Horn wrote:

> I'll see if I can get some larger repo and report back.  With my test
> repo with ~4000 files, it took around 0.25 seconds no matter if zero or
> ten --exclude patterns were given.

Thanks!

>> What about the hgignore contents? Does EXTRA-IGNORES in the Hg
>> implementation actually mean ALL-IGNORES, i.e. will we need to pass
>> the whole ignores list there?
> 
> No, "hg status --all" prints files with their status, e.g.,
> 
> $ hg status --all
> ? unregistered.txt
> I ignored.o
> C .hgignore
> C committed.txt

I think that was more of a "yes". :-)

> Right now, we don't collect files marked as "I"gnored.  As soon as you
> add extra ignores, files will actually be filtered:
> 
> $ hg status --all --exclude '*.o'
> ? unregistered.txt
> C .hgignore
> C committed.txt

What I wondered is whether running 'hg status --all --exclude 
'committed.*' would include 'ignored.o' in the output.

It does, and still with 'I' at bol. It's a good result, and it probably 
implies that ALL-IGNORES semantics might be a better choice, in case 
some people have *lots* of files ignores in their Hg repos (build 
artefacts, etc).

>> I've been toying with an implementation for Git which uses negative
>> pathspecs to specify all ignores (including the whitelist), instead of
>> modifying the ignores list. Performance-wise, it looks good enough, so
>> it seems my intuition was wrong. We could hit maximum command line
>> length this way, though this didn't happen with Emacs's gitignore,
>> which is not small. I wonder how much of a concern that would be.
>>
>> The actual implementation wasn't saved on disk and got eaten by a
>> reboot, but I can show it later if you like.
> 
> Sure, then I can check if that's doable with at least hg.

OK, a bit later. But it seems obviously doable with Hg: just add all 
includes with --exclude and avoid filtering by the status character.

>> There's a caveat, though: negative pathspecs have only been added
>> AFAICT in Git 1.9. Whereas CentOS Stable is on Git 1.8.3 currently.
>>
>> So we'll have to handle it somehow, e.g. use a fallback for that
>> version.
> 
> IMHO, the fallback is just use the existing "find" version, no?

Yes. Just worried about the number of cases where we would use the fallback.

>> That makes me more inclined to just hardcode two implementations (one
>> for Git and another for Hg) inside project.el. At least as the first
>> version of this feature.
> 
> I have no clear preference but as my main concern is better performance
> with our Git repo at work, I won't object.

Excellent.

>>> Right now, it uses `vc-file-tree-walk'...
>>
>> Shouldn't somebody reimplement it on top of 'find'?
> 
> I don't know.  It would surely be faster but there might be systems
> without 'find'.

Makes sense. So it would need a fallback as well. Maybe someday, then.