zsh-workers
 help / color / mirror / code / Atom feed
From: Sam Bostock <sam.bostock@shopify.com>
To: "Lawrence Velázquez" <larryv@zsh.org>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Abbreviate commit hash in prompt during git rebase
Date: Wed, 13 Apr 2022 13:53:40 -0600	[thread overview]
Message-ID: <CAHwnEohmcE7Wg6ZBdKmUgU-e7zryRgUXXWPJFRdxU9_nbZ=DpA@mail.gmail.com> (raw)
In-Reply-To: <58222599-b634-401b-b70f-3e5fd5633839@www.fastmail.com>

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

  reply	other threads:[~2022-04-14  1:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13  4:41 Sam Bostock
2022-04-13  5:38 ` Lawrence Velázquez
2022-04-13 19:53   ` Sam Bostock [this message]
2022-04-17 17:52     ` Daniel Shahaf
2022-04-17 20:08       ` Lawrence Velázquez
2022-04-17 20:17         ` Daniel Shahaf
2022-04-13 22:03 ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHwnEohmcE7Wg6ZBdKmUgU-e7zryRgUXXWPJFRdxU9_nbZ=DpA@mail.gmail.com' \
    --to=sam.bostock@shopify.com \
    --cc=larryv@zsh.org \
    --cc=zsh-workers@zsh.org \
    --subject='Re: [PATCH] Abbreviate commit hash in prompt during git rebase' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).