From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: A project-files implementation for Git projects Date: Sun, 22 Sep 2019 12:37:08 +0300 Message-ID: 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> <87impk675h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="220628"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 22 11:37:52 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 1iByJS-000vFB-Ez for ged-emacs-devel@m.gmane.org; Sun, 22 Sep 2019 11:37:50 +0200 Original-Received: from localhost ([::1]:45920 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iByJQ-0001cb-UF for ged-emacs-devel@m.gmane.org; Sun, 22 Sep 2019 05:37:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38074) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iByIr-0001cQ-UA for emacs-devel@gnu.org; Sun, 22 Sep 2019 05:37:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iByIq-0003OF-P2 for emacs-devel@gnu.org; Sun, 22 Sep 2019 05:37:13 -0400 Original-Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:44341) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iByIq-0003NY-GC for emacs-devel@gnu.org; Sun, 22 Sep 2019 05:37:12 -0400 Original-Received: by mail-lj1-x22f.google.com with SMTP id m13so10807797ljj.11 for ; Sun, 22 Sep 2019 02:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=55XO3HQf5AVmbfu9KsLOftdXvvkZC53IQQHzNIV12F8=; b=SKbGa4PK3CjfYMQDMM4YxZXBxlPm0nKvXKxFmLGlWEP+ofA6NtqgwapPhQSO+ZvTha rSxSEgzecYu42UCmcB1BkHdJ3MlrYrKOjwAk9oJeGfLgKgcrqaAwtf+7+qGEfEBtR3lC By7fjbQCZ1EcnZD4+QVqlFZMLJQt9Cl+mVMnaOsxxLgiSs9CFbslKPUvOnrPhdszAQlJ b4CxAvypeUeEErXTkK1Hm9LDpyBPU9CCT8LHRE971mrrX6qpMDepQgXA+1R8TUySS3iZ Tx1/kCfWBUjuo50xfjVhUkqCsIrgLvhPjmotlrkfuJ24XfMN25Q7DuiLbOLQNFS7AYwV BRxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=55XO3HQf5AVmbfu9KsLOftdXvvkZC53IQQHzNIV12F8=; b=BmncacHj3iwo2FOeoco/PLwFN2s3Lx3ynzA13icT6JENRXhQSgbPbwj82mZ67Le7lF K5Q0aT0jbtHLJJR8azQ01lzwI/1Vau0PKarELWGWRW3Wdlk2zT42SEYp6BoskoX84+cx c7ayHxEtpNYcbqj3rpBt0riY8WtMLbHZK05dXnWxgDoHgCLv7SHWsI2GViag5Ty1tZtM lS1D1yFMVuh8cd6xB8arj0ECrYfStT40EDQCLPLRM4Tsft0eUXMJzIKSH+gtEB05t0BP 3Gtab1TrV5Vr2jyI6+t6bUdJe0rMidmZ8JyTIuUjEBrkHsGixUA78EKCp58QRLm8JHTj FbYA== X-Gm-Message-State: APjAAAVMX3FulFjPlZDEiLqwhuHzLScMSO6NDNdZezIiQmnsuT5wNBi9 xCuAPj2VPu8SaiAKHIrI0TNYPGVLUVQ= X-Google-Smtp-Source: APXvYqxAE4CoY/3TejnrAHK8AeswEwadkiQjicapk1gwx3sYu0J3i0GeSEZ472ZbXWEicEZV/sfmmQ== X-Received: by 2002:a2e:9d4a:: with SMTP id y10mr11193245ljj.181.1569145030720; Sun, 22 Sep 2019 02:37:10 -0700 (PDT) Original-Received: from [192.168.1.125] (87-242-55.netrun.cytanet.com.cy. [87.228.242.55]) by smtp.googlemail.com with ESMTPSA id i128sm1543450lji.49.2019.09.22.02.37.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2019 02:37:10 -0700 (PDT) In-Reply-To: <87impk675h.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::22f 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:240235 Archived-At: 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 > 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). 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'?