From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9397 invoked from network); 23 Oct 2020 23:49:22 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2020 23:49:22 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1603496962; b=hw521ilkI9x66KV9WLrBF0jDZFMaTkL56OmSAwSxWd+lXZiPfoVYtJQR4IrImc+3K5BnSpVdMe LupheP2RFsUSF8Rx1MV+HHk4KMEj0GsnnQNvNfNtPugppctzo38EgwFHecBTQDJa1pSVWIywOf 7XgdBHM/5e08sVwQ5oixnJLudo4I5503jxwScDan99Tn0y7A59UYOiR0Ks8fnIgQujAImtMVdj /GV4F7ie9sg4lhNeIsIh+oWqyyRCIUHJN20bv+PlAXJ3Qssfzwjynab2nxgsvlDtJYwDc7F314 8HOFivP+6THrvdTGXrVYcyh0xse43yzpftFELfLqEEGhMQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (out5-smtp.messagingengine.com) smtp.remote-ip=66.111.4.29; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1603496962; bh=izXoK4bz3GLWUCvXYRd/3VsQgN91RqZ02amLSMVdCKY=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:MIME-Version: References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=UddktobqmzQ1S57E7QhbNewL2THYGyrjOEKyWPPsQEEumbGD+gaRf1ReZiSJFiz8XwIgzG3yqJ NcAbLPh/P7hMDGiq1kY+wb51s9j8HqFR3Nh2jneceEZ18FAx40nKNCZkF1bPT414oRD97tomTq fuuM0R6bbhvzOWgva+qfkQe7pyR4Azl0puuRyuYz/rmqizowHBYUBieS31aDVu12kOaYT1slSU 7VqNkSRcNheBpCygrOSgphrJKe6sLHawmod3T+u+5qN8xpvZlFQ6/0ZGQzvKBF3cEdXWOmvtln SN4zltbbqyUFbhjcPRDSVoQG6jjaRtwN7msjGqlNqNPY0Q==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=QOJsSm/oRyoIhhU80N8Eaw2gckwINYj0gC3y+hlNBts=; b=iXuIXaUQwJcVruKWnPlHQfKRmL bmYAJv0km3cFBDSB/WWrxHYgVjc9QDR17VfY6wrN1KB0lu+BZgE7IaaAqal4KjyNiXIDD1lmnRDFX /7ZMm2AHgtR3ZACZdKD4FyW4qTCCbav1lGWgMg8BYcZjf4Yu9btdc1HLwaSWgTTzS/YdmFLSFKCxk 9awVYJZWpUCTiguoK1Mbd5ykaMluzZBiYQFqpjCByPK4enWapwR0ysoIMOF/KnBRg6k5kHYYn//H+ KRPSGXOY8Dj/7Hk/EDhQzEFaIhzwY+kpui79juulMunEhIgx4A2Sb6MJShX6pP+R/EDlavSz7MEpT 8TzOS9EQ==; Received: from authenticated user by zero.zsh.org with local id 1kW6oA-000ID4-Go; Fri, 23 Oct 2020 23:49:18 +0000 Authentication-Results: zsh.org; iprev=pass (out5-smtp.messagingengine.com) smtp.remote-ip=66.111.4.29; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none Received: from out5-smtp.messagingengine.com ([66.111.4.29]:33151) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kW6nt-000I4O-ER; Fri, 23 Oct 2020 23:49:03 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F308C5C00E2; Fri, 23 Oct 2020 19:48:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 23 Oct 2020 19:48:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=fm1; bh=QOJsSm/oRyoIhhU80N8Eaw2gck wINYj0gC3y+hlNBts=; b=utaWMRPgM2pVqS0gWDIXIenfE1T382yKiAMqAg3R2Y bee5CLwpfkufD3l7bA0i2UgzJ8xfbSXGptPP9Ru6mbMfMpsssM7hEKdGcvt8Xhy8 MYfVqAbM+WTGVj8INeVEWuZUA/+uzXPXEnVw0qmYUgeSHtwRgoegd33+FpRgTJpe bd6QJvr4m+3vAKKWEjT5IXh0gt+FbN3t4GiTKWCivgt8F0x54cG+WYkL9IuMNjqI rG3d1U/v6i2ced1P8WWyg5tw9zCh7mi184F9vR8q5avHVa6ZRdcmnkjJpQXie3ar wb+BMQSLQsIhllT57xuYzhl/xXR7KY5dQWwKeLvUXmiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=QOJsSm/oRyoIhhU80N8Eaw2gckwINYj0gC3y+hlNB ts=; b=b0O0EweRSBxA72vVb+VuaXQ+gZJ1sewfu4QHYWan78f/Xdv3xafa5uwdH hVqX6d4OaCaK2UkJ+pgyP0Iiv9BVO1SC32g6ZRVfb7Pu+VknEP4k2Qo5rSg60RLf /M7ZhzqEhzNmrcyukLtGl5qiZ+mNOsZ3zufx7BZuPHKZTYgFp74wQD8yTZ+5jkgS MV7ASxmKQ06ABpLkV8Oli9FGsj/QE1HxgZ3kT8qjZ3jM9wykAtEpohYajS4dh3DT 4pYArvSvAjprM0lRCqzcSA9cLSofwgd66f4BRzkYVq18yvqDHwvbKoMFcllOU5ke iLgAFCzzXsv/SFdJwxlWI7ko+Z20Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkedugddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkjghfofggtgfgsehtqhdttdertdejnecuhfhrohhmpeffrghnihgv lhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenuc ggtffrrghtthgvrhhnpefhtdetfeehveeutdehuddtieefgeettedtjedtffehudeiieej leetteekudetheenucfkphepuddtledrieeirddufedrvddvjeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhh rghhrghfrdhnrghmvg X-ME-Proxy: Received: from tarpaulin.shahaf.local2 (bzq-109-66-13-227.red.bezeqint.net [109.66.13.227]) by mail.messagingengine.com (Postfix) with ESMTPA id 7669B3064680; Fri, 23 Oct 2020 19:48:59 -0400 (EDT) Received: from tarpaulin.shahaf.local2 (localhost [IPv6:::1]) by tarpaulin.shahaf.local2 (Postfix) with ESMTP id 4CJ1CY0hgyz34w; Fri, 23 Oct 2020 23:48:57 +0000 (UTC) Date: Fri, 23 Oct 2020 23:48:55 +0000 From: Daniel Shahaf To: Aleksandr Mezin Cc: zsh-workers@zsh.org Subject: Re: [PATCH] vcs_info: add 'find-deepest' zstyle Message-ID: <20201023234855.5a0c6290@tarpaulin.shahaf.local2> In-Reply-To: <20201023083444.1565608-1-mezin.alexander@gmail.com> References: <20201023083444.1565608-1-mezin.alexander@gmail.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Seq: 47486 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Aleksandr Mezin wrote on Fri, 23 Oct 2020 14:34 +0600: > Currently, vcs_info iterates over enabled VCS backends and outputs reposi= tory > status from the first backend that works (i.e. first backend that can fin= d a > repository). >=20 > But I prefer a different behavior: I want to see the status of the reposi= tory > closest to the current working directory. For example: if there is a Merc= urial > repository inside a Git repository, and I 'cd' into the Mercurial reposit= ory, > I want to see the status of Mercurial repo, even if 'git' comes before 'h= g' in > the 'enable' list. I suppose that's the Right thing to do in most cases: e.g., it's context-sensitive whereas the 'enable' style's value doesn't usually depend on the current directory. (Separately, in your example it might be nice to indicate that there's an "outside" Git repository, but that'd be a separate feature request.) > Because some people, apparently, want the old behavior of vcs_info, What's those people's argument? The default behaviour should be decided on on this list, not simply announced to this list as a _fait accompli_. > I made it configurable, and, by default, old behavior is kept. To > enable new behavior, enable 'find-deepest' zstyle: >=20 > zstyle ':vcs_info:*' find-deepest yes >=20 I'd probably set this in my dotfiles: in the rare cases that I nest repositories, I don't add files in the deeper repository to the shallower repository. > After this change, vcs_info will try all enabled backends, and choose the= one > that returns the deepest basedir path. Usually it will be the repository > closest to the current directory - if all basedirs are ancestors of the > current directory. I do not care about cases when a basedir isn't an ance= stor > (for example, if GIT_WORK_TREE is pointing to an unrelated directory). Would you clarify the last sentence (not the parenthetical but the part before it)? > Also, this patch adjusts VCS_INFO_detect_git and VCS_INFO_detect_cvs to m= ake > them set vcs_comm[basedir]. They were the only VCS_INFO_detect_* function= s not > setting it. Thanks. I don't recall if there's "How to write a backend" documentation, but so long as all existing backends get it right, we're probably covered well enough in practice. Going forward, we could heavily comment one of the backends and declare it documentation, as with Test/B01cd.ztst. > Signed-off-by: Aleksandr Mezin > --- > Doc/Zsh/contrib.yo | 9 +++++++ > .../VCS_Info/Backends/VCS_INFO_detect_cvs | 2 +- > .../VCS_Info/Backends/VCS_INFO_detect_git | 1 + > .../VCS_Info/Backends/VCS_INFO_get_data_git | 2 +- > Functions/VCS_Info/vcs_info | 25 ++++++++++++++++--- Please update _zstyle. > 5 files changed, 33 insertions(+), 6 deletions(-) >=20 > diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo > index 00f693664..88d00c0ac 100644 > --- a/Doc/Zsh/contrib.yo > +++ b/Doc/Zsh/contrib.yo > @@ -1238,6 +1238,14 @@ of unapplied patches (for example with Mercurial Q= ueue patches). > =20 > Used by the tt(quilt), tt(hg), and tt(git) backends. > ) > +kindex(find-deepest) > +item(tt(find-deepest))( > +By default, tt(vcs_info) tries backends in the order of 'enable' list, a= nd > +returns the output of the first backend that can find a repository. When > +tt(find-deepest) is set to tt(true), tt(vcs_info) will try all enabled b= ackends, > +and will choose the one that Multiple tweaks here. How about: By default, tt(vcs_info) tries backends in the order given by the tt(en= able) style, and operates on the repository detected by the first backend to successfull= y detect a repository. =20 When this style (tt(find-deepest)) is set to tt(true), tt(vcs_info) wil= l try all enabled backends, and will operate on [...] Wordier, yes, but "the output of a backend" didn't parse for me. > +returns the deepest tt(basedir) path. "basedir" is an implementation term; readers won't know what it means. Keeping it would be like having zshparam(1) document $? as "The value of=C2=A0tt(lastval)". If /foo/.${vcs} and /foo/bar/.${vcs} both exist (same value of ${vcs} in both) the style is set, the latter should be used. However, you don't seem to be handling this case in any way. I guess that if this patch is to be accepted, we'll have to go through all backends and verify that they prefer /foo/bar/.${vcs} to /foo/.${vcs} when both exist and the style is set appropriately. It's probably best if you go through backends you can install via your distro and ask -workers@ volunteers to go through any others. (Some backends will probably be left over, but we can cross that bridge when we come to it.) When /foo/.${vcs} and /foo/bar/.${vcs} both exist and =C2=ABfind-deepest=C2= =BB is set to _=C2=ABfalse=C2=BB_, might someone expect /foo/.${vcs} to be used? = (After all, one might reasonably presume flipping the style's value would _somehow_ affect vcs_info's behaviour.) Perhaps we can name the style more unambiguously? How about changing it from boolean to enum, as in: . zstyle ':vcs_info:*' detection-algorithm enablement-order zstyle ':vcs_info:*' detection-algorithm deepest-.vcs-dir . That'd also be more extensible. Separately, as implemented the style doesn't quite go by the _deepest_ basedir path. Rather, it goes by the one that _has more path components_.=C2=B9 That's not the same thing, at least if you take "X=C2= =A0is deeper than=C2=A0Y" to imply "X=C2=A0is a (possibly nested) subdirectory of= =C2=A0Y", which, I think, would be the appropriate semantics here. For instance, given the pair of repository root paths {/foo/bar/baz, /lorem/ipsum}, the patch will prefer /foo/bar/baz, even though it's not "deeper than" /lorem/ipsum. I don't think setting find-deepest should affect the relative precedence of /foo/bar/baz and /lorem/ipsum=E2=80=A6 =E2=80=A6 unless either of the two directories happens to be an ancestor of= cwd, in which case there's an argument to be made that that directory should be preferred. (I hope we don't have to worry about symlinks here.) Moreover, the above description wasn't entirely accurate. The patch doesn't count path components; it counts slashes. That's not equivalent, because of things like =C2=AB/foo/bar=C2=BB, =C2=AB/foo/bar/=C2= =BB, =C2=AB/foo/./bar=C2=BB, =C2=AB/foo//bar=C2=BB, and =C2=ABbar=C2=BB (the las= t one depends on cwd, of course). For instance, =C2=AB/foo///bar=C2=BB will be considered deeper th= an =C2=AB/foo/bar/baz=C2=BB. I think a reasonable next step would be to nail down what repository should be chosen, given $PWD and a set of existing .${vcs} dirs (possibly more than one of those per value of ${vcs}). For instance: 1. The .${vcs} dir whose parent is an ancestor of ${PWD}; if there's more than one of these, the closest ancestor; if there's more than one of _these_, the first enabled. 2. If there's no such .${vcs} dir, then a .${vcs} dir from the first backend in enablement order. If there's more than one of these, then XXX. (TODO: What if the first backend in enablement order identifies two repository directories, and one of them is an ancestor of the other? Which one will be used?) > +Usually it will be the repository closest to the current directory. Documentation shouldn't say "usually" without also explaining what happens in the _unusual_ case. > +++ b/Functions/VCS_Info/Backends/VCS_INFO_detect_cvs > @@ -7,5 +7,5 @@ setopt localoptions NO_shwordsplit > -[[ -d "./CVS" ]] && [[ -r "./CVS/Repository" ]] && return 0 > +[[ -d "./CVS" ]] && [[ -r "./CVS/Repository" ]] && vcs_comm[basedir]=3D.= (:P) && return 0 =C2=AB.(:P)=C2=BB won't be expanded here. Cheers, Daniel