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

["Lawrence Velázquez" <larryv@zsh.org>]

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