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 18206 invoked from network); 26 Nov 2021 08:09:04 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 26 Nov 2021 08:09:04 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1637914144; b=sXDhCSEcsxp5d+XamMmKuuHIWtrBMxWMEQo84Vi/MRY3JxJELKFPCXDZTLwGXXWgQJyWsbuRHo apgMX5FDUucmb9W77VBrcWqllslF+/JV98og7YuN5sA5OpA8I2vuGxdzawGIz2gTtOLTJPMtOU pbAL1K3KF9o+xMxzids+bQvlVTj5aub5sJi+vIIXgUbyjA89AxnCvBnL8rz/g9dF2RmMBFJ5B0 r29j1llV5top11CAFDLPDduQ3xo6hBRCaoMdiRpSwTvhlu4qGsMusy2e2aDH9WWrUJ5v/HJ+U3 BxTiJPjj1yFiAMQ92xO2IvHAdOS1eWDuQSQlJUaK0KULkg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (wout3-smtp.messagingengine.com) smtp.remote-ip=64.147.123.19; dkim=pass header.d=daniel.shahaf.name header.s=fm2 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-20210803; t=1637914144; bh=WXdWWXw7WPy+tfkWs7roexQjlVjrDl/2Kh+C3oRSFag=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=Lq3IDQ79EBqpR7+Z6oJbqPy+L+VXJEY1Zkj7ki631xz3QH96T2vvsZdvS9MR+zYvevEg+K9JNU x5EbunW8OgRuQc33/yQg/UfWeQ8qxt+SL0tiZSHTBfNGuU4FHFjjG1FuXvawBH0duS8+Ohf+8h BbTC29ImOUrI1zkZ+aZOoF9UDi3N2ufjYVasxr6Gd9j6QI+UF+dEFmCW3LZcsnlvJJ47pzi6B8 6AWucTa94H/+Ev49VUQ7ilGzum1Dag2hBECy3BVrAIlGIw+4WKg+TfVWijBm7/c7btgunwfYg5 VojFHUI/QkSbchBe1VAHEi6HLDVEormWG7brOrH77b8jig==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References: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=v6CpURWIev7yHS4uLecp+xX2gmEnQNXYDL3OpI/yQ74=; b=b09l0YN7dvUGe6a8s8l6pJzStb jh7mnlQWFnohQIBFWQDPfR18NoiUqIgtrYioLuqTaVepsEI1lzskvDSHI1Hf5PMUBdkMTdewD2lxA 4B7Q4VUJB8Cg05aUkJsCfo4MQLWoIAyyXhrl9sWWzX7d4tCMLtyBGLJIyuLLmpNni7trn1o5KVna9 AG0GwVqkj0BPDWdPiEw8jNzgpsWgWAcXNCRE9U2q3Hn0Hr0QeLN0k4ptYB0AClHAh4n4s2yXCan1b 0i5E7ObBWyFsp3Ti1AftpQUsMyeff9RrnuZEJ9yNkNp/1tC2Xerz2fycDJaFfGyFQ61OADXejOM39 gf62Srrg==; Received: from authenticated user by zero.zsh.org with local id 1mqWI2-000Bfg-95; Fri, 26 Nov 2021 08:09:02 +0000 Authentication-Results: zsh.org; iprev=pass (wout3-smtp.messagingengine.com) smtp.remote-ip=64.147.123.19; dkim=pass header.d=daniel.shahaf.name header.s=fm2 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 wout3-smtp.messagingengine.com ([64.147.123.19]:53565) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1mqWHm-000BOp-8N; Fri, 26 Nov 2021 08:08:48 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 770C03200AC9; Fri, 26 Nov 2021 03:08:43 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 26 Nov 2021 03:08:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=fm2; bh=v6CpURWIev7yHS4uLecp+xX2gmEnQNXYDL3OpI/y Q74=; b=uNDwQ/EOTsMAAERdvvJmV6PFwMvG77XDfd7/lIMVL6yYmJ4frZxTQKn0 gD6LMvkEQ+GqpJtSWB8rLxt8ZDvWjiIsp5eDKFOh6ohLqyD36h0ZUKWNQjmjd/ih OinXWz/hmYoMDHeBx4IrUA5h8DV7enuzHfUUDdcloOdOKkGhx4xNDwlbqyZ6WEKM gp9/wK81Zs/mO2UGiCaS7jhIcKkSzvGDP/jY0S6GAOc0hgtDk6tRB3Mw7ic1xFC/ TH3mERW99Idr59ufFvMb033rdCsj/12Y9rcykqrym4KK00AxJAIFPwzrjpHeuzJU /f4EdeYZYv7tLgVNLlB/In1cax7WOw== 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=v6CpURWIev7yHS4uLecp+xX2gmEnQNXYDL3OpI/yQ 74=; b=AOiCvow+sV22S850mfaes65X8Y56S09JdHoGmnlUNnYLZ1mqxveubt4ia e66WAmqia/xH7zqtxxVVPIQMpycsupUcE/3nRVf2kOPjB/h4xZqgAUvWdVSLc+nK ayugTSI6uwZN6nlRebmJIJQxYYEfA/T9t+1kLM8VwVXzx3udgrfz4m+d6FJiYP2w p/MGPrF+ePAhpW3L2CkmqinQFsuG1GjD8J6NEuUcREBYENDfcpw4RwIyy/FZfqGr 0GBbY6+PsaVwDXk5iHURHo8tozKEB/D2YFzCkje8oCx1lljAIiZ49lkB5yTYhBSN zFgqCcw9I2FhJhY1BrpYZVI8LimLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedugdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjggfsehtkedttddtreejnecuhfhrohhmpeffrghn ihgvlhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpefgkefgfeejgfdvvdfguddtleelkedvfeetiedtudfhveev veduhfdvveeffedvueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 26 Nov 2021 03:08:42 -0500 (EST) Received: by tarpaulin.shahaf.local2 (Postfix, from userid 1005) id 4J0nSQ3pfjz4yG; Fri, 26 Nov 2021 08:08:38 +0000 (UTC) Date: Fri, 26 Nov 2021 08:08:38 +0000 From: Daniel Shahaf To: Aleksandr Mezin Cc: zsh-workers@zsh.org Subject: Re: [PATCH v5] vcs_info: choose backend by basedir Message-ID: <20211126080838.GA17935@tarpaulin.shahaf.local2> References: <20210604061421.172899-1-mezin.alexander@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210604061421.172899-1-mezin.alexander@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Seq: 49603 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: Sorry for how long this is taking. I've not had much time recently. (I haven't even had time to commit all my own patches.) I think the summary as of right now (before this post) is still workers/48329. (I did another review after that, but answers to it have been incorporated into v5 here.) -workers@: given that several people have mentioned they weren't familiar with vcs_info enough to review/apply this, I'd like to particularly solicit reviews of the new functionality, as described in the log message and docs patch. I'm not looking for review of the implementation or for copyediting of the docs, but for reviews of the functionality described in the docs. Before I get to the details, I'd like to repeat that I'm aware of how old this patch is — it's two years old this week — and I'll adjust my review granularity accordingly, as far as reasonable without cutting corners on my committability standards. Aleksandr Mezin wrote on Fri, Jun 04, 2021 at 12:14:21 +0600: > Previously, vcs_info iterated over enabled VCS backends and output repository > status from the first backend that works (i.e. first backend that can find a > repository). > > But I prefer a different behavior: I want to see the status of the repository > closest to the current working directory. For example: if there is a Mercurial > repository inside a Git repository, and I 'cd' into the Mercurial repository, > I want to see the status of Mercurial repo, even if 'git' comes before 'hg' in > the 'enable' list. > We seem to have consensus to add such a functionality, established in workers/48329 (grep for "First things first"). > This patch adds a new algorithm for vcs_info to choose the backend: > > 1. Among backends whose basedir isn't an ancestor of the current directory, > old algorithm is used: whichever comes first in 'enable' list. > > 2. If all backends return basedirs that are ancestors of the current directory, > the one with basedir closest to the current directory is chosen. > > As far as I know, unless the user has set basedir manually (GIT_WORK_TREE), > all backend return basedirs that are ancestors of the current directory. > Backends that return non-ancestor basedirs have higher priority to show the > status of that manually-configured repository. > Okay, so the order is actually: 1. Backends that returned a non-ancestor directory 2. First detected backend out of those that don't have choose-closest-backend set 3. Closest ancestor backend out of those that do have choose-closest-backend set Now, I'm sure that achieves your original design goal (from 44918) of preferring hg to git inside ~/git-repo/hg-repo, but overall it seems rather arbitrary. What's the rationale for this particular order? How does one remember what has precedence over what? (E.g., command-line options generally have precedence over environment variables because command-line options are assumed to have been set "closer" to running the command.) My question from 48329 stands: . There doesn't seem to be any way to shadow a GIT_WORK_TREE setting, other than to temporarily set the enable/disable styles so as to exclude git entirely. Is that a problem? . To be clear, the question is why $GIT_WORK_TREE should have precedence over VCS_INFO_detect_fossil() regardless of style settings. I think we could simplify this design by dropping the ability to set the style on a per-backend basis. Let there be two modes: the current one (of detected backends, choose whichever comes first in the 'enable' style's value) and the new one (of detected backends, choose the one whose worktree root is deeper), with a global knob to choose between them. That should suffice. Furthermore, why doesn't the first mode suffice on its own? That is: for your ~/git-repo/hg-repo situation, why is it not sufficient to ensure that hg precedes git in the value of the 'enable' style? I couldn't find the answer in the past threads. > The algorithm used by vcs_info can be configured using 'choose-closest-backend' > zstyle: > > zstyle ':vcs_info:*' choose-closest-backend yes > > By default, old algorithm is used. > > It can also be configured per-backend: > > zstyle ':vcs_info:hg:*' choose-closest-backend no > > This effectively moves the backend into group (1), as if its basedir is never > an ancestor of the current directory. Not sure how useful this is though. Well, I suppose one might set: . zstyle ':vcs_info:*' choose-closest-backend yes zstyle ':vcs_info:git:*' choose-closest-backend no . The effect of the second line would be to give git precedence when it's the outer VCS. I don't immediately see a use-case for this. Perhaps if someone has several sibling worktrees, and they then create an outer worktree encompassing all inner worktrees so as to make/revert changes in lockstep across all trees? That's relevant if the outer worktree isn't of the same VCS as the inner ones. > Signed-off-by: Aleksandr Mezin > --- > v4: back to boolean zstyle, keep old behavior by default, documentation > v5: described expected vcs_info[basedir] use in a comment, addressed Daniel's > questions in comments. Hope this helps. I'm sure it feels like we're going backwards, or in circles, but one always feels a jolt backwards when a car starts moving ☺ Cheers, Daniel