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

Hi Tassilo,

On 22.09.2019 11:56, Tassilo Horn wrote:

No, it doesn't slow down the listing (in comparison to just hg status
--all).  However, my test hg repo is not extraordinarily large (~4000

If performance is C*N where N is the number of files, then we can compare the times to complete on any medium-sized repo, as long as the list of ignores is significant (though they don't need to match anything).

Anyway, if the perf looks good to you we could push the improvement first and then deal with negative reports.

BTW, can Hg support extra whitelist entries as well?

"hg status --all" prints everything including ignored files.  An
--exclude restricts the output and filters the output so that matching
files are not listed.  --include also restricts the output so than only
files matched by such an include pattern are listed.

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?

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.

Ok, I see.  So that would be this and it seems like now we have the same
semantics as with the hg version:

Very good. Support for rooted entries and whitelist can be easily added here.

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.

A quick look at bzr suggests there's just a way restrict positively,
i.e., like --include with hg.

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.

Yeah, I wonder if we should treat this as a VC operation. On the other
hand, the fallback implementation could just as well use 'find'.

Right now, it uses `vc-file-tree-walk'...

Shouldn't somebody reimplement it on top of 'find'?

reply via email to

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