From: "Lawrence Velázquez" <email@example.com> To: "Daniel Shahaf" <firstname.lastname@example.org>, "Sam Bostock" <email@example.com> Cc: firstname.lastname@example.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: <email@example.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. 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
next prev parent 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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).