[PATCH] Abbreviate commit hash in prompt during git rebase

[PATCH] Abbreviate commit hash in prompt during git rebase

[Sam Bostock]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5309 bytes --]

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

[Lawrence Velázquez]

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

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

[Sam Bostock]

[-- Attachment #1: Type: text/plain, Size: 4161 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5589 bytes --]

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

[Daniel Shahaf]

Sam Bostock wrote on Wed, Apr 13, 2022 at 13:53:40 -0600:
> Hi Lawrence,
> 
> Thanks for the reply!
> 

Have you seen my previous reply to you, <https://zsh.org/workers/50057>?
(For obvious reasons I'll re-send this question to you in a minute from
another address of mine.  Apologies in advance for the duplicate.)

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

The operative word here is "guarantee".  If we truncate to, say, 12 hex
digits, that's 48 bits (= 12 nibbles), so a repository would need to
have 2**24 commits (≈ 16M) in order to have a ≈50% chance of having two
commits with the same first 12 nibbles.  (That's _commits_, not
_objects_, since IIRC «d41d8cd^{commit}» v. «d41d8cd^{blob}» is a valid
way to disambiguate.) Only the largest/oldest projects would have
history DAGs this large.¹

And if we truncate "too soon" and the resulting hash is ambiguous, then
what?  Would that be a problem?

- It wouldn't break the use-case of looking at the prompt after «git
  commit» or «git rebase --continue» to confirm the command worked.

- It wouldn't break the use-case of reviewing the scrollback and knowing
  what the state was before each command.
  
- It _would_ break the use-case of copying the hash into the command
  line, because then git would error out about the ambiguous prefix.
  The workaround would be to extract the full hash from the reflogs or
  from rebase's todo list.

  This use-case is so common for me that I had my zshrc store the commit
  hash in a global variable so I can easily use it in interactive
  commands.  (I do «typeset -g y=…» in zshrc and then «git show $y»
  interactively.)

So, do we actually need to *guarantee* uniqueness?

¹ For instance, FreeBSD's ports repository, which started in 1994, has
0.6M commit objects (per «git rev-list --all --count») and autogenerates
12-nibble short hashes.  (I didn't choose this repository because of
this property; it's just a repository I happened to have handy.)

> Given we're already in somewhat of an edge case (rebase in progress), is
> the penalty still a problem?
> 

I don't consider rebases an edge case, so, "Yes.".

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

Every time.

Cheers,

Daniel

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

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

[Lawrence Velázquez]

On Sun, Apr 17, 2022, at 1:52 PM, Daniel Shahaf wrote:
> Sam Bostock wrote on Wed, Apr 13, 2022 at 13:53:40 -0600:
>> 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.

FWIW, this description of core.abbrev from git-config(1) (v2.35.1)
doesn't say anything about *guaranteeing* uniqueness.

    core.abbrev
	Set the length object names are abbreviated to.  If unspecified
	or set to "auto", an appropriate value is computed based
	on the approximate number of packed objects in your repository,
	which hopefully is enough for abbreviated object names to
	stay unique for some time.  If set to "no", no abbreviation
	is made and the object names are shown in their full length.
	The minimum length is 4.

If git really does ensure that abbreviated hashes are unique, then
it's either documented elsewhere or not documented at all.  The
weather is very nice right now, so I shall decline to dive into the
Git codebase at this time :)

> So, do we actually need to *guarantee* uniqueness?

I think allowing users to adjust truncation length through a style
ought to suffice for users who need it.

That would also avoid coupling prompt appearance to the configuration
of a separate piece of software, which is a notion that I like less
and less the more I think about it.  I can easily imagine a user
who might want to see full hashes in Git output but not in their
prompt.

-- 
vq

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

[Daniel Shahaf]

Lawrence Velázquez wrote on Sun, Apr 17, 2022 at 16:08:34 -0400:
> That would also avoid coupling prompt appearance to the configuration
> of a separate piece of software, which is a notion that I like less
> and less the more I think about it.  I can easily imagine a user
> who might want to see full hashes in Git output but not in their
> prompt.

Agreed, but one could use the «command» style to have vcs_info invoke
Git as «git -c core.abbrev=42», in order to use core.abbrev as part of
the solution without this problem.

Cheers,

Daniel

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

[Daniel Shahaf]

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"