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? In particular, why use a static value, when git’s default behavior is to compute a value based on the current number of objects in the repository? (Edit: just noticed this post is over 10 years old. Maybe git didn’t have this automatic default behavior back then.)
For what it’s worth, jj has an even better solution, which is to highlight the shortest unique prefix in each specific hash it displays.
Edit: just noticed this post is over 10 years old.
It would be helpful if the title was edited to feature the release date. Context is king. So many things are absurd with regards to the current state, but are sorely lacking a few years ago.
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.
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.
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.abbrevis configured? In particular, why use a static value, when git’s default behavior is to compute a value based on the current number of objects in the repository? (Edit: just noticed this post is over 10 years old. Maybe git didn’t have this automatic default behavior back then.)For what it’s worth,
jjhas an even better solution, which is to highlight the shortest unique prefix in each specific hash it displays.It would be helpful if the title was edited to feature the release date. Context is king. So many things are absurd with regards to the current state, but are sorely lacking a few years ago.
What are you referring to?
The article is about abbreviated forms, not full hashes. The Linus quote is specifically about abbreviation.
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.
I think you missed the last sentence of the post:
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.
deleted by creator