Hi Lawrence,
Thanks for the reply!
Git's abbreviation mechanism ensures uniqueness, rather than strictly truncating. If I'm not mistaken, the core.abbrev setting is effectively just a minimum for how many characters to include, with git including as many additional characters as required to avoid colliding with another object in the repository. I believe the default is determined using a heuristic based on the number objects in the repository.
So we could make it a setting and do truncation ourselves, but then we'd be displaying a value without uniqueness guarantees.
Given we're already in somewhat of an edge case (rebase in progress), is the penalty still a problem?
Also, while I'm not familiar with the inner workings of vcs_info, I'm wondering if we recompute this every time the prompt is rendered, or if we lazily compute the values only when the rebase progresses?
Sam
On Tue., Apr. 12, 2022, 11:38 p.m. Lawrence Velázquez, <
larryv@xxxxxxx> wrote:
Hi Sam,
On Wed, Apr 13, 2022, at 12:41 AM, Sam Bostock wrote:
> First time contributor here
Welcome!
> diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> b/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> index e45eebc8e..dd9c40ab4 100644
> --- a/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> +++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> @@ -209,27 +209,15 @@ elif [[ -d "${gitdir}/rebase-merge" ]]; then
> return 0
> ;;
> (''(p|pick|e|edit|r|reword|f|fixup|s|squash)' '*)
> - # The line is of the form "pick $hash $subject".
> - # Just strip the verb and we're good to go.
> - p=${p#* }
> + # Typically, the line is of the form "pick $longhash
> $subject\n".
> # Special case: in an interactive rebase, if the user
> wrote "p $shorthash\n"
> # in the editor (without a description after the
> hash), then the .../done
> # file will contain "p $longhash $shorthash\n" (git
> 2.11.0) or "pick $longhash\n"
> # (git 2.19.0).
> - if [[ $p != *\ * ]]; then
> - # The line is of the form "pick $longhash\n"
> - #
> - # Mark the log message subject as unknown.
> - # TODO: Can we performantly obtain the subject?
> - p+=" ?"
> - elif (( ${#${p//[^ ]}} == 1 )) && [[ ${p%% *} == ${p#*
> }* ]]; then
> - # The line is of the form "p $longhash
> $shorthash\n"
> - #
> - # The shorthash is superfluous, so discard it,
> and mark
> - # the log message subject as unknown.
> - # TODO: Can we performantly obtain the subject?
> - p="${p%% *} ?"
> - fi
> + # Given we don't reliably have the subject, and the
> full hash is needlessly long
> + # for a prompt, we simply extract the hash (second
> word) and delegate to git to
> + # format it as "$shorthash $subject" according to
> git's hash abbreviation config.
> + p=$(${vcs_comm[cmd]} log -1 --pretty=format:'%h %s'
> $p[(w)2])
> ;;
> (''(x|exec) *)
> # The line is of the form 'exec foo bar baz' where
> 'foo bar
It strikes me as a regression to run git if we already have the
subject; vcs_info is slow enough as it is. Could this be reserved
for the edge cases where we don't have the subject?
(This would preclude what is arguably your primary goal, which is
using core.abbrev to choose between short and long hashes. But
that amounts to using git as a glorified string slicer. Perhaps
the choice could be determined by a style instead, and we could do
the truncation ourselves?)
--
vq