Re: A project-files implementation for Git projects

[Tassilo Horn <tsdh@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan, Dmitry & Eli,

>> But what should this do?  From a vc list-files function I'd expect
>> (and document) that it lists all and only tracked files.  So should
>> the default implementation use find to locate all files and then
>> check each one if it is tracked using vc-state (or something alike)?
>
> I'd pass it a "fallback" function, so you'd have something like:
>
>     (defun vc-default-list-files-fast (backend ... fallback)
>       (funcall fallback))
>
> and in the call you'd do
>
>     (vc-call-backend (vc-responsible-backend dir)
>      'list-files-fast ... #'cl-call-next-method)

Ah, right, that's a good idea!

>> (vc-backend "~/Repos/el/emacs") => nil
>> But that's my emacs git checkout...
>
> Ah, indeed, it seems you want vc-responsible-backend instead.

(vc-responsible-backend "~/Repos/el/emacs") => Git

Yup, that's it!

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10.09.2019 16:39, Tassilo Horn wrote:
>> But what should this do?  From a vc list-files function I'd expect
>> (and document) that it lists all and only tracked files.  So should
>> the default implementation use find to locate all files and then
>> check each one if it is tracked using vc-state (or something alike)?
>
> I'd really like it to be more feature-rich. I.e. to accept arguments
> which files it will return, or blacklist/whitelist.
>
> In my limited testing, Git can handle it and will still return the
> list of files much faster than the current find-based solution.
>
> It's a bit more complex to implement, though. That's why it has been
> on my list for a while without much progress.

Yes, I guess ideally it would take a list of vc-states like up-to-date,
edited, needs-update (probably with the exclusion of unregistered) and
list the files in any of the given states.

I'll start simple with listing all tracked files...

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Date: Tue, 10 Sep 2019 08:25:17 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> Also, I think most vc backends have a way to list tracked files but
>> not all those are faster than find is.  "git ls-files" is much faster
>> than find but short testing revealed that "hg files" is much slower.
>
> "hg files"?  Did you mean "hg locate", perhaps?  Or are there new
> commands in hg that were added lately?  (My installation of Mercurial
> is quite old, so maybe I'm out of touch.)

Seems so.

--8<---------------cut here---------------start------------->8---
$ hg files --help
hg files [OPTION]... [FILE]...

list tracked files

    Print files under Mercurial control in the working directory or
    specified revision for given files (excluding removed files). Files
    can be specified as filenames or filesets.

    If no files are given to match, this command prints the names of all
    files under Mercurial control.
--8<---------------cut here---------------end--------------->8---

> Anyway, whether 'find' or the VC-specific way is faster might be OS
> dependent.  I'm guessing you tested on GNU/Linux;

Yes.

> on MS-Windows, I get the opposite results for both hg and bzr (let
> alone Git), even though my build of GNU Find is highly optimized and
> generally much faster than other ports available on Windows.  Plus,
> 'find' might not be available on Windows, whereas the VC backend for a
> repository must be available, almost by definition.
>
> So at the very least this should be customizable, and in general,
> unless 'find' is orders of magnitude faster, I'd prefer to use VC in
> all cases.

Ok, you are right.  I'll work on it and report back.

Bye,
Tassilo