bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 12 Nov 2023 00:00:13 +0200
> Cc: 67062@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 11/11/2023 09:41, Eli Zaretskii wrote:
> > If this is a Git-only issue, perhaps it would be better to have a
> > Git-only option, instead of defining a whole new VC method?
> 
> Our general approach is to prefer global options and dynamic dispatch on 
> backends, resorting to using per-backend options when it's much easier 
> to do.

Which I think is the case here.  What other VC backend has such long
revision strings?  I couldn't think of any.  And for Git, there could
be the choice of either shortening the SHA1 signature or using what
"git describe" returns.  Which is why I suggested an option specific
to vc-git.

> In this case it might actually be more difficult to go the second route 
> since the intention is to only use the short hash in this particular 
> place. vc-annotate is common code and it will need to indicate that 
> intention to the backend somehow.

I'm not sure I follow.  All we need is a new function to call instead
of vc-working-revision, that's all.  That new function will indicate
the intention to the backend.  Sounds easy enough.

IOW, if Git is a special case, there's IMO nothing wrong with having
code that is specific to Git.  Inventing a VC method that will do
nothing in every VCS but Git sounds un-economical and not very elegant
to me, FWIW.