From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: A project-files implementation for Git projects Date: Sun, 22 Sep 2019 10:56:42 +0200 Message-ID: <87impk675h.fsf@gnu.org> References: <8736h9rdc4.fsf@gnu.org> <87mufcfz1u.fsf@gnu.org> <87tv9kz2x6.fsf@gnu.org> <87a7bbjdwe.fsf@gnu.org> <87a7ba8uvx.fsf@gnu.org> <87pnk2zvvy.fsf@gnu.org> <87sgows6wy.fsf@gnu.org> <87ef0dy18z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="58963"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 22 10:57:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iBxg2-000FAG-NO for ged-emacs-devel@m.gmane.org; Sun, 22 Sep 2019 10:57:06 +0200 Original-Received: from localhost ([::1]:45802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBxg0-0000hH-Ut for ged-emacs-devel@m.gmane.org; Sun, 22 Sep 2019 04:57:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34238) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBxfp-0000hB-Gk for emacs-devel@gnu.org; Sun, 22 Sep 2019 04:56:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iBxfo-0005Bp-LP; Sun, 22 Sep 2019 04:56:52 -0400 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:58377) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1iBxfh-000722-PS; Sun, 22 Sep 2019 04:56:47 -0400 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 6985820EB0; Sun, 22 Sep 2019 04:56:45 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 22 Sep 2019 04:56:45 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeigddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufhffjgfkfgggtgesthdtredttdertdenucfhrhhomhepvfgrshhsihhl ohcujfhorhhnuceothhsughhsehgnhhurdhorhhgqeenucffohhmrghinhepshhtrggtkh hovhgvrhhflhhofidrtghomhenucfkphepgeeirdektddrjedtrddvheenucfrrghrrghm pehmrghilhhfrhhomhepthhhohhrnhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlih hthidqkeeijeefkeejkeegqdeifeehvdelkedqthhsughhpeepghhnuhdrohhrghesfhgr shhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Original-Received: from thinkpad-t440p (p2e504619.dip0.t-ipconnect.de [46.80.70.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 1B291D6005A; Sun, 22 Sep 2019 04:56:43 -0400 (EDT) Mail-Followup-To: Dmitry Gutov , emacs-devel@gnu.org In-Reply-To: (Dmitry Gutov's message of "Thu, 19 Sep 2019 19:01:44 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240233 Archived-At: Dmitry Gutov writes: Hi Dmitry, >> where extra-includes works in addition to the standard VC ignore >> rules (.gitignore, .hgignore). Or do you want to override the >> VC-internal rules? > > I'm afraid it might not work as well if we try to treat all (modified) > ignores the same. In my understanding, the speed with which Git lists > files to a large extent stems from not having to apply the ignores to > the already-registered files. Someone should benchmark this, but I > think if we use the "negative pathspec" approach mentioned below for > all ignores together, it might slow down file listing by an order of > magnitude or several. > >> At least for Git and Hg, I came up with reasonable implementations: >> [...] > > Terrific, thank you! How is Hg's performance with this approach? Does > adding a few ignores (like 5 or 10) slow down the output measurably? 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). > 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. >> --8<---------------cut here---------------end--------------->8--- >> There's a semantic difference between Git and Hg in the treatment of >> extra-ignores. With Git, the extra-ignores do not rule out committed >> files (i.e., they are only effective for untracked files) while for >> Hg, they also rule out committed files. I think the Hg semantics are >> probably better > > Better and important, IMO. > >> but I don't see how to change the Git version so that it acts the >> same way (except by re-filtering in lisp, of course), do you? > > Previously suggested: > > https://stackoverflow.com/questions/36753573/how-do-i-exclude-files-from-git-ls-files/53083343#53083343 > > That means converting all extra-ignores into negative pathspec strings. Ok, I see. So that would be this and it seems like now we have the same semantics as with the hg version: --8<---------------cut here---------------start------------->8--- (defun vc-git-list-files (&optional dir include-unregistered extra-ignores) (let ((default-directory (or dir default-directory)) (args '("-z"))) (when include-unregistered (setq args (append args '("-c" "-o" "--exclude-standard")))) (when extra-ignores (setq args (append args (cons "--" (mapcar (lambda (i) (format ":!:%s" i)) extra-ignores))))) (mapcar #'expand-file-name (cl-remove-if #'string-empty-p (split-string (apply #'vc-git--run-command-string nil "ls-files" args) "\0"))))) --8<---------------cut here---------------end--------------->8--- So basically "git status ... -- '*.el'" corresponds to "hg status --all --include '*.el'" whereas negative pathspecs correspond to hg's --exclude. A quick look at bzr suggests there's just a way restrict positively, i.e., like --include with hg. >> I haven't looked at the other backends. I guess bzr will probably be >> doable, too. However, for SVN, there's no way to list unregistered >> files. A correct (but horribly slow) default implementation should >> also be doable. > > 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'... Bye, Tassilo