help / color / mirror / code / Atom feed
From: "Lawrence Velázquez" <larryv@zsh.org>
To: "Daniel Shahaf" <d.s@daniel.shahaf.name>,
	"Sam Bostock" <sam.bostock@shopify.com>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Abbreviate commit hash in prompt during git rebase
Date: Sun, 17 Apr 2022 16:08:34 -0400	[thread overview]
Message-ID: <b8d68d76-9437-4c73-9b8e-f8c6a1d76eae@www.fastmail.com> (raw)
In-Reply-To: <20220417175228.GP27526@tarpaulin.shahaf.local2>

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.

	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


  reply	other threads:[~2022-04-17 20:09 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
2022-04-17 17:52     ` Daniel Shahaf
2022-04-17 20:08       ` Lawrence Velázquez [this message]
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:

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

  git send-email \
    --in-reply-to=b8d68d76-9437-4c73-9b8e-f8c6a1d76eae@www.fastmail.com \
    --to=larryv@zsh.org \
    --cc=d.s@daniel.shahaf.name \
    --cc=sam.bostock@shopify.com \
    --cc=zsh-workers@zsh.org \
    --subject='Re: [PATCH] Abbreviate commit hash in prompt during git rebase' \


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


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