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 7655 invoked from network); 27 Oct 2020 01:02:23 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 27 Oct 2020 01:02:23 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1603760543; b=aznGOVoTAnis94vnEyoRGcCsgJG3Vbe5mZakKonjITn27TayvdK0Qi/XmErBI0+VtyhP+vkF4E XLQFyVycVexLVII06QpRGs0ugiFJvNQ2GXiRAeqY9nEJ3hgqkrP0MPxOrbCCjCFVlCv11h0hxJ LWGS3wlLm96AGmkLx9PCrp8eGmgyG8Nbl/2jVEpdYiL+vrheX+ejbJFq0bJfU4lZNiYChjQCnM zSNpP3jgtnm43ANRLYbOgg+4OJ83uqC9rH6AJKjadd7B2ZbgxTO/VpEcdQTvho7EEE8+ix+oqK UcqUI709JiUsNWis9Iqe54sq1oFXZ6HpeX3ukYeGHEAHRw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (smtprelay03.ispgateway.de) smtp.remote-ip=80.67.31.30; dmarc=none header.from=zsh.org; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1603760543; bh=SIM7D4/G3M9HPHJSpob0abigvVFJfy6dcpInuHLjQo0=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:To:From:DKIM-Signature; b=fWYe9gvI5cl0zqcNICSIic+fZgvUIBFvfFqqb5Sva7NgheY8Xjp7wgHGd/Y5M1/x9T6rqOAvag Fm5cUORV+qMeEvlmTSFOd56Kn8R9FsbA63E4Y9mgqprmhfyLzUiHF8f2ZzQeUaXzPxpoLepjZ/ g+1geEoRh9SptbVjRMdkMxk5tZIVYXbtfxpw4nDWlymGoo4sbuzClNYovXN2KLlGwoimJBMcfH 1j7Uw4wET9wD+Cz0o2ggfM1dvn75M9LPS55BHOqW8yMo7yBpko3iIsKnOUl9oatUG8SN+UmSR2 FEfHUg6qVA+rQ4xZhNIXOwT1G8tiRj4lIWE0q5lFU5pgoQ==; 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:Message-ID:Date:References:In-Reply-To:Subject:To: From:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=9LKtUmuZEwBN/qeOUfFs0q6hLg8bAoH9Sg42Rjaq180=; b=Jedd+2uXWUxO0iYy8LTwpaptKS uzBgdLTKBHSHBPOd6emdqb8XFH+z6YrvdHEIVFe5iYikQN8ovdq8rcFefncgKATCKTWFO4oS9hsv1 oJQi9t849UmTrsotOkAMLLRmDLC0IcLZYteduaozMUMN81OXdZLd2dXNC8jypkEjkhRlXFMkS1YZm CWQAisMvjHWC8LDfbQxcAil/AVCozbBFpymfdejo/Tl8qaDJ3lvFOuBnx10EQsS4eKlqpu6Im6Ajo EXcQDBA8sbMHNXRO7V/h1DoKONEKi/lRnsImOEGSsLwF6BWnRVfyOZbOf0LtN9J2aXXd/T/oJpd/Z RLqsv4xw==; Received: from authenticated user by zero.zsh.org with local id 1kXDNU-0007c3-5j; Tue, 27 Oct 2020 01:02:20 +0000 Authentication-Results: zsh.org; iprev=pass (smtprelay03.ispgateway.de) smtp.remote-ip=80.67.31.30; dmarc=none header.from=zsh.org; arc=none Received: from smtprelay03.ispgateway.de ([80.67.31.30]:54699) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kXDNE-0007S2-1Y; Tue, 27 Oct 2020 01:02:04 +0000 Received: from [80.141.186.10] (helo=jim.voodoo.lan) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kXDN7-00072I-LH for zsh-workers@zsh.org; Tue, 27 Oct 2020 02:01:57 +0100 Received: by jim.voodoo.lan (Postfix, from userid 1000) id 3CE7361D019; Tue, 27 Oct 2020 02:01:52 +0100 (CET) From: Frank Terbeck To: zsh-workers@zsh.org Subject: Re: [PATCH] vcs_info: add 'find-deepest' zstyle In-Reply-To: <56643e6c-0f7c-49f0-8089-4d4a42008dae@www.fastmail.com> (Daniel Shahaf's message of "Mon, 26 Oct 2020 20:58:25 +0000") References: <20201023083444.1565608-1-mezin.alexander@gmail.com> <20201023234855.5a0c6290@tarpaulin.shahaf.local2> <87mu0clbw2.fsf@ft.bewatermyfriend.org> <37168-1603506679.130606@RR8o.26Eg.GGvC> <20201025195401.3c54c6a2@tarpaulin.shahaf.local2> <878sbtlx0o.fsf@ft.bewatermyfriend.org> <56643e6c-0f7c-49f0-8089-4d4a42008dae@www.fastmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Date: Tue, 27 Oct 2020 02:01:52 +0100 Message-ID: <87v9ewjxbz.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Df-Sender: NDMwNDQ0 X-Seq: 47506 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: Hey, Daniel Shahaf wrote: > Frank Terbeck wrote on Sun, 25 Oct 2020 23:13 +00:00: >> Daniel Shahaf wrote: [=E2=80=A6] >> > +1, primarily because git is much more stateful (e.g., interrupted >> > rebases). >>=20 >> I think it's mostly because git is a decentralised system, where more >> information is available without having to touch a networked system, >> like the central server in centralised systems. The latter will kill >> latency dependant use cases, such as prompts. > > I don't see how vcs_info's admittedly increased usefulness under Git > follows from Git's being decentralized and from more information being > available locally. The fact that the system *can* do things *locally* enables things like notifying the user about differences in tracked files =E2=80=94 like stage= d and unstaged changes. > On the other hand, consider =C2=ABgit rebase -i=C2=BB which I cited as an= example. > There is no conceptual problem with implementing the equivalent of that > feature in Subversion=C2=A0=E2=80=94 and if that were done, showing state= in the > prompt would become much more useful under that backend. Certainly =E2=80=94 I don't doubt features being present in the git-backend= that are not applicable with other systems. I was merely stating my impression. I don't think it's a coincidence that the two most feature-rich backends are the ones for git and mercu- rial. I think the low-latency nature of local information enables this. That is not to say that other factors cannot play a role, but this is the one that I always considered the =E2=80=9Cobvious=E2=80=9D reason. Cle= arly only for some values of =E2=80=9Cobvious=E2=80=9D. :) > Furthermore, under Subversion I use hooks to display some additional > information I find useful: a list of changelist names and the > modified/switched/partial-depth indications from `svnversion` output. > None of these states is inherent to Subversion's centralized > nature: there's nothing stopping git and hg from implementing the > equivalents of =C2=ABsvn changelist=C2=BB, =C2=ABsvn switch=C2=BB and =C2= =ABsvn update > --set-depth=3Dexclude=C2=BB. (To be clear, I'm not saying they should. = I'm > just saying those features are orthogonal to centralization/decentralizat= ion.) Sure. I wonder however, how long this takes. My experience with subver- sion was always that any time I had to hit the network, and you need to for basically everything, latency was unbearable for use in prompts. Even with servers in the same building. Not having to access the network enables using this sort of information because you get to it quicker. > And the reason all this is so? vcs_info shows the _current_ state, > which is a moving target. It doesn't show the history[=E2=80=A6] It could of course, but like you I don't think it would be all that useful. [=E2=80=A6] > P.S. Speaking of my hooks, I've got some other ones that might be of > independent interest: I have my svn prompts show the `svnversion` > output's revision range, e.g., "42:100", rather than just whatever `svn > info --show-item=3Drevision ./` happens to be; Sounds useful. But I always thought svnversion also had to hit the net- work, to figure out if the working copy has local modifications. Does this run in finite time, or would this be mostly useful with local ser- vers? > I print the topmost patch > in quilt addon mode, and the commit being rebased in interrupted > rebases; and I indicate presence of GIT_* envvars and per-repository > addons (e.g., git-annex(1), vcsh(1)). This sounds interesting. Care to share? :) Regards, Frank --=20 In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925