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@zsh.org>
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
>