zsh-workers
 help / color / mirror / code / Atom feed
From: Frank Terbeck <ft@zsh.org>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] vcs_info: add 'find-deepest' zstyle
Date: Tue, 27 Oct 2020 02:01:52 +0100	[thread overview]
Message-ID: <87v9ewjxbz.fsf@ft.bewatermyfriend.org> (raw)
In-Reply-To: <56643e6c-0f7c-49f0-8089-4d4a42008dae@www.fastmail.com> (Daniel Shahaf's message of "Mon, 26 Oct 2020 20:58:25 +0000")

Hey,

Daniel Shahaf wrote:
> Frank Terbeck wrote on Sun, 25 Oct 2020 23:13 +00:00:
>> Daniel Shahaf wrote:
[…]
>> > +1, primarily because git is much more stateful (e.g., interrupted
>> > rebases).
>> 
>> 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 — like staged and
unstaged changes.


> On the other hand, consider «git rebase -i» which I cited as an example.
> There is no conceptual problem with implementing the equivalent of that
> feature in Subversion — and if that were done, showing state in the
> prompt would become much more useful under that backend.

Certainly — 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 “obvious” reason. Clearly only for
some values of “obvious”. :)


> 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 «svn changelist», «svn switch» and «svn update
> --set-depth=exclude».  (To be clear, I'm not saying they should.  I'm
> just saying those features are orthogonal to centralization/decentralization.)

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[…]

It could of course, but like you I don't think it would be all that
useful.


[…]
> 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=revision ./` 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
-- 
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


  reply	other threads:[~2020-10-27  1:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23  8:34 Aleksandr Mezin
2020-10-23 23:48 ` Daniel Shahaf
2020-10-24  0:13   ` Frank Terbeck
2020-10-24  0:56     ` Bart Schaefer
2020-10-25 20:04       ` Daniel Shahaf
2020-10-24  2:31     ` Oliver Kiddle
2020-10-25 19:54       ` Daniel Shahaf
2020-10-25 23:13         ` Frank Terbeck
2020-10-26 20:58           ` Daniel Shahaf
2020-10-27  1:01             ` Frank Terbeck [this message]
2020-11-04  8:42               ` Daniel Shahaf
2020-10-28  1:33   ` Aleksandr Mezin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9ewjxbz.fsf@ft.bewatermyfriend.org \
    --to=ft@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).