Re: A project-files implementation for Git projects

[Dmitry Gutov]

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.