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

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Frank Terbeck wrote on Sun, 25 Oct 2020 23:13 +00:00:
> Heya,
> 
> Daniel Shahaf wrote:
> > Oliver Kiddle wrote on Sat, 24 Oct 2020 04:31 +0200:
> […]
> >> I don't have much use for nested repositories but vcs_info tends to be
> >> more use with git than subversion.
> >
> > +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.

Decentralization is reflected in, for instance, the data model (a DAG of
commits) and in the existence of the «git push $remote» syntax.  Neither
of those is directly reflected in information typically extracted into
prompts: for instance, when the checked out branch tracks a remote
branch, vcs_info doesn't have a built-in facility for displaying the
name of the remote.

Same goes for having the history available locally.  vcs_info git
prompts do not typically show information from commits other than the
current one.  The only exceptions I can think of are the detached HEAD %b
expando fallback code that uses `git describe`/`git name-rev` and the
statistics expandos in the patch-format style.

If showing previous commits' data were a common requirement, one would
have expected the use-server style to be used by at least some of the
centralized backends.  However, that style is used only by the p4
backend for detection (as opposed to interrogation) and by the
'checkout' variant of the bzr backend.

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.

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.)

And the reason all this is so?  vcs_info shows the _current_ state,
which is a moving target.  It doesn't show the history, and doesn't need
to, because the history is in the user's mental cache anyway.  That's
also why the git-rev-list(1) uses in Misc/vcs_info-examples print the
statistics of the local HEAD relative to the upstream HEAD, but not the
statistics of the upstream HEAD relative to an empty repository.

Cheers,

Daniel

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; 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)).