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

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.


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

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.


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.

reply via email to

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