this post was submitted on 23 Apr 2024
18 points (90.9% liked)

Git

2826 readers
34 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
Ategon
canpolat
jnovinger
18
How short can Git abbreviate? (blog.cuviper.com)
submitted 4 months ago by canpolat to c/git
5 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] Kissaki 1 points 4 months ago (1 children)

I’m not sure I understand what issue Linus et al. are trying to solve. If the full hash is used whenever a commit reference is saved somewhere, then why does it matter how core.abbrev is configured?

What are you referring to?

The article is about abbreviated forms, not full hashes. The Linus quote is specifically about abbreviation.

[Linus] He recommends kernel developers use 12 characters

For a large code base you can expect to further grow continuously for a long time, it makes sense to already use more than a minimum abbreviation so that you references remain unique, even if a decades time.

Configuring a wider and explicit abbreviation width that will remain constant is preferable because the displayed references are what you will copy and reference. It doesn't make sense to work with shorter abbreviations locally, but wider abbreviations when communicating with others. It'd be a hassle to translate and risky to miss doing.

[–] BatmanAoD 1 points 4 months ago (1 children)

I think you missed the last sentence of the post:

Finally, when you reference a Git hash for posterity, e.g. in another commit message, I’d recommend always using the full value.

The git config is just for display purposes in terminal output. That only needs to be unique as of the time it's displayed; and as I noted, the current default behavior is to adjust the size dynamically, so the displayed hash segment is always unique no matter how big the repo is.