Hi!

First time contributor here; hopefully I have appropriately formatted this!

Please find the description of the change below.

I don't have an environment setup to test this, but the following proof of
concept works:

# Typical case
% msg="pick $(git rev-parse origin/master) wrong subject"
% echo $msg
pick 06e5ec914fdedac6446e02c9427a1706dda9c505 wrong subject
% echo $(git log -1 --pretty=format:'%h %s' $msg[(w)2])
06e5ec914 50013: skip %test if a chunk in %prep fails

# Edge case mentioned in old comments for git 2.19.0
% msg="pick $(git rev-parse origin/master)"
% echo $msg
pick 06e5ec914fdedac6446e02c9427a1706dda9c505
% echo $(git log -1 --pretty=format:'%h %s' $msg[(w)2])
06e5ec914 50013: skip %test if a chunk in %prep fails

# Edge case mentioned in old comments for git 2.11.0
% msg="pick $(git rev-parse origin/master) $(git rev-parse --short
origin/master)"
% echo $msg

pick 06e5ec914fdedac6446e02c9427a1706dda9c505 06e5ec914
% echo $(git log -1 --pretty=format:'%h %s' $msg[(w)2])

06e5ec914 50013: skip %test if a chunk in %prep fails

I copied the use of `${vcs_comm[cmd]}` from elsewhere in the file to invoke
`git`.

- Sam



The full commit hash is quite long to be included in a prompt.
Given it is unlikely that the hashes from the prompt need long term
uniqueness,
we can display the abbreviated hash instead.

If, for some reason, the user wants the full hash, they can set the git's
`core.abbrev` config.

Ths change also allows us to reliably display the commit subject, even in
the
edge cases where it is not present in the `.git/rebase-merge/done` file.

https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreabbrev
---
 .../VCS_Info/Backends/VCS_INFO_get_data_git   | 22 +++++--------------
 1 file changed, 5 insertions(+), 17 deletions(-)

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
--
2.35.1