From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A project-files implementation for Git projects Date: Tue, 17 Sep 2019 15:03:37 +0300 Message-ID: <838sqnw2na.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> <838sqpx9eq.fsf@gnu.org> <83y2yow9dy.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="44490"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 17 14:12:06 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 1iACKw-000BPC-9B for ged-emacs-devel@m.gmane.org; Tue, 17 Sep 2019 14:12:02 +0200 Original-Received: from localhost ([::1]:45200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iACKv-0004rN-0j for ged-emacs-devel@m.gmane.org; Tue, 17 Sep 2019 08:12:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59951) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iACCs-0008EH-Op for emacs-devel@gnu.org; Tue, 17 Sep 2019 08:03:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iACCr-00051Z-Ax; Tue, 17 Sep 2019 08:03:41 -0400 Original-Received: from [176.228.60.248] (port=2827 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iACCp-0000T1-DC; Tue, 17 Sep 2019 08:03:40 -0400 In-reply-to: (message from Dmitry Gutov on Tue, 17 Sep 2019 13:46:19 +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:240105 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Tue, 17 Sep 2019 13:46:19 +0300 > > On 16.09.2019 18:25, Eli Zaretskii wrote: > > >> Should we sacrifice some correctness for speed? > > > > No, but it was never my intent to say otherwise. What is "correct" > > here? E.g., 'find' will find _all_ the files, including the ignored > > one -- is that "correct"? > > 'find' can handle an arbitrary list of ignores, including whitelisting > entries (a feature which I've yet to add, but still). So you are going to convert the likes of .gitignore to a long list of 'find's -name arguments? Instead of just using the tools that can do this at a flip of a command-line argument? Why? > Not every file that's registered in a VCS should be seen as part of the > project, and some of the unregistered (and gitignore-d) still should be > (e.g. config files that are created by every developer individually but > still should be editable by them through Emacs and project-find-file). That's a separate topic, IMO, but IME (which is admittedly thin) any "project" kind of feature requires the user to register the files somehow, before the file appears in the tree shown by the project's UI. > >> If backends other than Git (and maybe Hg) can't return untracked > >> files > > > > Which backend cannot do that? Bzr can (you just need to call it > > twice), and the other two also can. So I think we have no problem > > here. > > Tassilo said that Bzr can't, I haven't checked. That's not exactly what Tassilo said, and "bzr help ls" is just a few keystrokes away of each one of us. > >> We could make up some performance using filenotify and caching, so that > >> 'find', though slower, would at least be called infrequently. > > > > That's over-engineering, I think. > > Really? Consider: we have to maintain the find-based approach anyway > since not everyone uses Git/Hg/Bzr. Where there's no VCS back-end, 'find' will have to do, and if it's slow, there's not much we can do about it. > And the filenotify-based cache would do one job. IME, filenotify doesn't scale well, so I won't recommend it for non-toy projects in this context. > Conceptually, at least, it should be simpler than coercing several > VC systems into doing the job of 'find' with ignore/whitelist > entries not exactly matching VCS's view of the repository. I think you are wrong here. It is 'find' that needs to be coerced to do a job that is not really its prime, and a project's view is in most cases almost exactly that of the VCS used for the project. The difference is just-now added files that were not yet registered, and how many of these can there be?