Re: [PATCH] vcs_info: add 'find-deepest' zstyle

[Frank Terbeck <ft@xxxxxxx>]

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