From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#42966: 28.0.50; vc-dir: wrong backend Date: Sat, 17 Oct 2020 23:01:09 +0300 Message-ID: References: <54k0vq420i.fsf@fencepost.gnu.org> <87pn5h1j4b.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8661"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: Glenn Morris , sds@gnu.org, 42966@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 17 22:02:22 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kTsPG-0002Af-89 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Oct 2020 22:02:22 +0200 Original-Received: from localhost ([::1]:52256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTsPF-0007MN-9m for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Oct 2020 16:02:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57936) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTsOw-0007M1-PK for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2020 16:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52286) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kTsOw-000119-EQ for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2020 16:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kTsOw-0005F1-Ce for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2020 16:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Oct 2020 20:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42966 X-GNU-PR-Package: emacs Original-Received: via spool by 42966-submit@debbugs.gnu.org id=B42966.160296488020098 (code B ref 42966); Sat, 17 Oct 2020 20:02:02 +0000 Original-Received: (at 42966) by debbugs.gnu.org; 17 Oct 2020 20:01:20 +0000 Original-Received: from localhost ([127.0.0.1]:35599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kTsOG-0005E6-B2 for submit@debbugs.gnu.org; Sat, 17 Oct 2020 16:01:20 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:39080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kTsOE-0005Ds-5i for 42966@debbugs.gnu.org; Sat, 17 Oct 2020 16:01:18 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id y12so7149156wrp.6 for <42966@debbugs.gnu.org>; Sat, 17 Oct 2020 13:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FT7BVyM6ypVHke1YPu3KrVeOVvbQZUndWUGhu+0lPgg=; b=p3rzPrKH125uqLjyIqMnx1ziamP68DxNsFVM905zhECkyQOCpDULa9OzEt8kc0nXmw CdPcMy0tyPhJKbG3J9ls5+zy6Y11juWelPUSgDJOyBrzLA2d9H8Wlsi04m7VcwLBerKh DS5TlhXKlZ1f+47ko+5gyKozm8ETu7PoSvugxcn/8ln/8ph0w6RUNj5ia7PXRwECEyFD rP5Ii/MU1HKxcfgqgv+d85xhy61DvdOsQS95N+jhnxJhYLUYKZnJBHDpJDexO02RePg6 8bHP0JvJZixF4TRWQ6u6Evg9PcW3GAQp1cpUYa1tLOvaI+7WrpaXXKM7+3SfT7yfJMAm 59Bg== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FT7BVyM6ypVHke1YPu3KrVeOVvbQZUndWUGhu+0lPgg=; b=tlf8ko+Vga2NZ0kNJGed2e1aP3jcwCn3J3YeAQIn5f1XTEo3D/Zyxtac1kKfOn95Tx c9nFJ5QrwXx8gN47YBsi41Uv9zdVzyFGjbZZPS06fis6VaKIFh7YQPiSXI5x9IqyUZkJ ROYpiNnnKdWonU/fEDRWOmk+X+LfhvwqHLto6Szu5K/ctz8DwrUc6DXAyQZDN6vx3HBJ OkHkBlfzuohDTOczEBD2F6vQBFfAiLCPMuPbDu88qiFOZDy+LiHIHmoq/7mIGDmVXUnF TqeOsjngDJaVvwuwRRp5Mq/djLpnfdlsNoOgJzPtNxWdPtZmqRgrBIbcJvEXylfwyTdu jyzQ== X-Gm-Message-State: AOAM532gICeZlltGFV8ym0wnjrGv8EfGNWXfipnWIkOiaTRWW2UyDnbz 3uLu7S0nTC1IMwxTHnxByW4mr2T3kP4H0g== X-Google-Smtp-Source: ABdhPJzNHCaMGsi1jbtTsetxte0474S03Us7/kD+hmr1/j+Xra+pWInQnhk5SxnlDhqV8qnAPGUXfQ== X-Received: by 2002:adf:f0c3:: with SMTP id x3mr11494485wro.343.1602964871998; Sat, 17 Oct 2020 13:01:11 -0700 (PDT) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id z18sm6248018wrs.82.2020.10.17.13.01.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Oct 2020 13:01:11 -0700 (PDT) In-Reply-To: <87pn5h1j4b.fsf@gnus.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:190833 Archived-At: On 17.10.2020 09:06, Lars Ingebrigtsen wrote: > Dmitry Gutov writes: > >> On 16.10.2020 18:35, Glenn Morris wrote: >>> See eghttps://debbugs.gnu.org/3807#21 from 11 years ago. >> >> Stefan's suggestion is pretty sensible. >> >> Though it'll require a rework of the corresponding VC backend >> actions. Not sure if it's possible to do in a backward-compatible >> fashion. > > (The suggestion is to recurse upwards and ask each backend "are you > responsible for this directory, then?") Or, more low-level, if we find that every backend follows the pattern of aliasing vc-xyz-responsible-p to vc-xyz-root, and calling vc-find-root in the latter's implementation, we could opt for creating a backend action that returns the "witness" file name (e.g. ".git"), and then construct a regexp from all witness file names, and pass it to 'directory-files' as MATCH. Depending on the cost of certain things, this could end up being much faster, both locally and remotely. > That makes sense, but it's just a performance hack, isn't it? The > result should be the same as the less invasive "loop over all the > backends and collect the most specific one". Pretty much. Except it should naturally limit the traversal up the directory tree, so it feels like a good architecture, not just a "hack". The backward compatibility headache might not be worth it, though.