From: Tassilo Horn <tsdh@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: A project-files implementation for Git projects
Date: Mon, 23 Sep 2019 09:42:50 +0200 [thread overview]
Message-ID: <874l13h30l.fsf@gnu.org> (raw)
In-Reply-To: <f0721d3c-ac52-22ce-2c5c-b388d1bee3f7@yandex.ru> (Dmitry Gutov's message of "Sun, 22 Sep 2019 12:37:08 +0300")
Dmitry Gutov <dgutov@yandex.ru> writes:
Hi Dmitry,
>> 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
>> files).
>
> 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).
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.
> Anyway, if the perf looks good to you we could push the improvement
> first and then deal with negative reports.
Yes.
>>> 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?
No, "hg status --all" prints files with their status, e.g.,
$ hg status --all
? unregistered.txt
I ignored.o
C .hgignore
C committed.txt
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
> 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, 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.
IMHO, the fallback is just use the existing "find" version, no?
>> 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.
I have no clear preference but as my main concern is better performance
with our Git repo at work, I won't object.
>>> 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'?
I don't know. It would surely be faster but there might be systems
without 'find'.
Bye,
Tassilo
next prev parent reply other threads:[~2019-09-23 7:42 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 9:19 A project-files implementation for Git projects Tassilo Horn
2019-09-06 12:52 ` Stefan Monnier
2019-09-10 6:25 ` Tassilo Horn
2019-09-10 12:56 ` Stefan Monnier
2019-09-10 13:39 ` Tassilo Horn
2019-09-10 13:56 ` Stefan Monnier
2019-09-11 11:00 ` Tassilo Horn
2019-09-11 20:01 ` Tassilo Horn
2019-09-13 20:38 ` Tassilo Horn
2019-09-14 0:29 ` Dmitry Gutov
2019-09-14 16:26 ` Tassilo Horn
2019-09-15 18:56 ` Dmitry Gutov
2019-09-16 2:27 ` Eli Zaretskii
2019-09-16 3:36 ` Dmitry Gutov
2019-09-16 15:25 ` Eli Zaretskii
2019-09-17 10:46 ` Dmitry Gutov
2019-09-17 12:03 ` Eli Zaretskii
2019-09-17 12:55 ` Dmitry Gutov
2019-09-17 13:14 ` Eli Zaretskii
2019-09-19 15:33 ` Dmitry Gutov
2019-09-19 17:29 ` Eli Zaretskii
2019-09-20 11:25 ` Dmitry Gutov
2019-09-20 12:59 ` Eli Zaretskii
2019-09-20 13:28 ` Dmitry Gutov
2019-09-20 13:45 ` Stefan Monnier
2019-09-20 13:54 ` Dmitry Gutov
2019-09-20 14:12 ` Michael Albinus
2019-09-20 14:30 ` Eli Zaretskii
2019-09-20 14:51 ` Dmitry Gutov
2019-09-20 15:04 ` Michael Albinus
2019-09-22 9:23 ` Dmitry Gutov
2019-09-20 14:55 ` Michael Albinus
2019-09-20 15:55 ` Eli Zaretskii
2019-09-20 15:01 ` Stefan Monnier
2019-09-20 15:59 ` Eli Zaretskii
2019-09-20 17:32 ` Stefan Monnier
2019-09-20 17:49 ` Eli Zaretskii
2019-09-20 18:04 ` Stefan Monnier
2019-09-20 14:23 ` Eli Zaretskii
2019-09-20 14:48 ` Dmitry Gutov
2019-09-16 13:32 ` Tassilo Horn
2019-09-17 11:06 ` Dmitry Gutov
2019-09-18 17:15 ` Tassilo Horn
2019-09-19 16:01 ` Dmitry Gutov
2019-09-22 8:56 ` Tassilo Horn
2019-09-22 9:37 ` Dmitry Gutov
2019-09-23 7:42 ` Tassilo Horn [this message]
2019-09-23 12:22 ` Dmitry Gutov
2019-09-27 16:17 ` Tassilo Horn
2019-09-30 0:09 ` Dmitry Gutov
2019-09-30 0:25 ` Stefan Monnier
2019-09-30 6:50 ` Dmitry Gutov
2019-09-30 17:09 ` Stefan Monnier
2019-10-01 8:19 ` Dmitry Gutov
2019-10-01 12:31 ` Stefan Monnier
2019-10-01 13:10 ` Stefan Monnier
2019-10-01 23:38 ` Dmitry Gutov
2019-10-03 9:25 ` Felician Nemeth
2019-10-03 10:32 ` Dmitry Gutov
2019-10-03 11:15 ` Felician Nemeth
2019-10-03 12:31 ` Dmitry Gutov
2019-10-03 14:39 ` Felician Nemeth
2019-10-03 14:42 ` Dmitry Gutov
2019-10-03 15:10 ` Felician Nemeth
2019-10-03 15:15 ` Dmitry Gutov
2019-10-01 8:11 ` Dmitry Gutov
2019-10-03 8:33 ` Tassilo Horn
2019-10-03 13:19 ` Dmitry Gutov
2019-10-03 17:15 ` Tassilo Horn
2019-10-03 22:49 ` Dmitry Gutov
2019-10-04 7:47 ` Tassilo Horn
2019-10-04 7:58 ` Tassilo Horn
2019-10-04 13:16 ` Dmitry Gutov
2019-10-04 8:49 ` Tassilo Horn
2019-10-04 12:57 ` Dmitry Gutov
2019-10-04 13:59 ` Tassilo Horn
2019-10-04 15:24 ` Dmitry Gutov
2019-10-04 12:16 ` Stefan Monnier
2019-10-04 13:08 ` Dmitry Gutov
2019-10-03 7:41 ` Tassilo Horn
2019-10-03 12:33 ` Dmitry Gutov
2019-10-03 12:51 ` Tassilo Horn
2019-10-04 5:52 ` Co-authoring and attribution in commit message (was: A project-files implementation for Git projects) Kévin Le Gouguec
2019-10-04 8:33 ` Co-authoring and attribution in commit message Dmitry Gutov
2019-10-04 21:36 ` Karl Fogel
2019-10-05 6:55 ` Eli Zaretskii
2019-10-03 23:02 ` A project-files implementation for Git projects Dmitry Gutov
2019-09-14 0:33 ` Dmitry Gutov
2019-09-14 16:43 ` Tassilo Horn
2019-09-15 8:29 ` Dmitry Gutov
2019-09-15 9:06 ` Dmitry Gutov
2019-09-10 13:57 ` Robert Pluim
2019-09-10 14:24 ` Dmitry Gutov
2019-09-10 14:41 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874l13h30l.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).