[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (fo
From: |
Eli Zaretskii |
Subject: |
bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git) |
Date: |
Sun, 12 Nov 2023 08:03:44 +0200 |
> 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.
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Jim Porter, 2023/11/10
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Eli Zaretskii, 2023/11/11
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Jim Porter, 2023/11/11
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Dmitry Gutov, 2023/11/11
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Jim Porter, 2023/11/11
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git),
Eli Zaretskii <=
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Dmitry Gutov, 2023/11/12
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Eli Zaretskii, 2023/11/12
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Dmitry Gutov, 2023/11/12
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Juri Linkov, 2023/11/12
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Dmitry Gutov, 2023/11/12
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Jim Porter, 2023/11/12
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Juri Linkov, 2023/11/13
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Dmitry Gutov, 2023/11/13
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Eli Zaretskii, 2023/11/13
- bug#67062: 30.0.50; [PATCH] Abbreviate the revision in 'vc-annotate' (for Git), Jim Porter, 2023/11/12