Re: [PATCH] Abbreviate commit hash in prompt during git rebase

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Sam Bostock wrote on Tue, Apr 12, 2022 at 22:41:46 -0600:
> First time contributor here;

Welcome!

> hopefully I have appropriately formatted this!
> 

Nope.  Your MUA inserted hard line breaks, both in prose (e.g., after
"uniqueness") and in the diff, breaking it.  That may have affected only
the text/plain version of the body.

The standard workaround for diffs is to send them as attachments named
*.txt.  Configuring one's email client to not munge linebreaks or
whitespace is also an option (and would help with the prose linebreaks
too).  You seem to use gmail; I don't know the "Be friendly to patches"
incantation for that off the top of my head.

> Please find the description of the change below.
> 
> I don't have an environment setup to test this,

There's Functions/VCS_Info/test-repo-git-rebase-merge, though admittedly
it's not easy to discover.

> 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
⋮
> 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.
> 

Specifically, it's included in the prompt via the %p expando of
«patch-format», which currently gives, say, «d759c823c2019ab9d5d1d56ac0cd2f9fb0948b76
r7: Append a line» (using the test script), 

That's then interpolated into the prompt via the %m expando of
«actionformats» (which isn't even used by the default settings; I'm glad
to know it's nevertheless used ☺).

Shortening the hash makes sense.

With my setup I actually already get «d759c823c201 r7: Append a line»
because I use a custom gen-applied-string hook that does truncation
itself; similar to the one in Misc/vcs_info-examples:297, plus manually
truncating ${patch_name_or_filename} to its first 12 characters (when
under git or hg and not under quilt).  The magic number 12 is hardcoded
in my zshrc.

Now, the test script's output (minimized by me):

    [in gen-applied-string] typeset -g -a argv=( 'd759c823c2019ab9d5d1d56ac0cd2f9fb0948b76 r7: Append a line' … )
    typeset -g vcs_info_msg_0_='[5+2=7] [d759c823c2019ab9d5d1d56ac0cd2f9fb0948b76 r7: Append a line] [2]'
    typeset -g vcs_info_msg_1_=''

The part inside the second set of square brackets is, as mentioned, the
expansion of %p in patch-format.

The hash and subject are two different attributes of the "patch" (=
thing described by a single gen-applied-string argument).  If we weren't
already combining them into a single string, we'd never start doing
that.  For instance, my setup colors the hash and subject differently.

How about if we added two new expandos, one that expanded only to
d759c823c2019ab9d5d1d56ac0cd2f9fb0948b76 and one that expanded only to
"r7: Append a line"?  Then truncation could be achieved easily by using
the %12.12x syntax to truncate to 12 characters (cf. "Truncate Long
Hashes" in Misc/vcs_info-examples:137, and colouring the hash and
subject differently wouldn't require writing a hook.

At this point I suppose we could deprecate %p… which might be a good
reason to rethink the way those arguments are passed to the
applied-string hook, which in turn might help find a more elegant
alternative to workers/49726.

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

Is this merely a _side effect_ of implementing hash truncation, or is it
something that should be done anyway, even if hash truncation is
implemented in a way that doesn't lend itself to also obtaining the
subject for free?  In the latter case, we might want to make the extra
git run conditional on some style (perhaps «use-simple» which already
exists; perhaps not).

WDYT?

Cheers,

Daniel
(the lists are down as I write this, so y'all will receive this with
a delay, but we're working on bringing them back up)

> ---
>  .../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"