Why don't you ask Linus, I'm sure he will calmly and respectfully explain the answer while apologizing for the trouble :)
The beginning of Git supporting other hash algorithms
11–20 of 128 posts
Re: The beginning of Git supporting other hash algorithms
#12Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.
If you have a repo with a lot of GPG signed commits, or you just don't want to change all your commit IDs (because you reference them in other places), then it'd be very valuable to be able to have a repo that's mixed old and new hashes.
Also your Git binary, if compiled with only the One True Hash™, wouldn't be able to work with older repos at all because the hashes it's calculating are now different.
(Edit: Another benefit of generalizing this is so that if/when, in the future, the new hash algorithm must be abandoned due to weaknesses, Git tooling will have been already introduced to the notion that hashes can be different and should hopefully be a less involved migration the next time around)
Re: The beginning of Git supporting other hash algorithms
#13Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.
Backwards compat requires that both old and new hashes work at the same time. A simple typedef is unlikely to handle all the semantics and space needed for such a change...
It is often hard to generalize when N=1. Now that the N=1 use case is established and we are moving towards N=2, it is painfully obvious to all that a better abstraction is needed.
Typedef or no, we would still need a full audit of the code to find spots where people "inlined" the expansion.
IMO, Linus should have done better here -- no crypto hash lasts forever, but this code is far cleaner than useless layers of abstraction.
Re: The beginning of Git supporting other hash algorithms
#14Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.
[deleted]
Re: The beginning of Git supporting other hash algorithms
#15Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.
Backwards compat requires that both old and new hashes work at the same time. A simple typedef is unlikely to handle all the semantics and space needed for such a change... It is often hard to generalize when N=1. Now that the N=1 use case is established and we are moving towards N=2, it is painfully obvious to all that a better abstraction is needed. Typedef or no, we would still need a full audit of the code to fin…
Perhaps you haven't read Linus' comments where he stated (more than a decade ago) that the usage of SHA1 here isn't for "security"?
(Hint: that's why GPG signing commits is an option.)
Re: The beginning of Git supporting other hash algorithms
#16FWIW, Fossil released a version with backwards compatibility, configurable graceful upgrades a week ago: https://www.fossil-scm.org/index.html/doc/trunk/www/changes....
Re: The beginning of Git supporting other hash algorithms
#17I'm the person who's been working on this conversion for some time. This series of commits is actually the sixth, and there will be several more coming. (I just posted the seventh to the list, and I have two more mostly complete.) The current transition plan is being discussed here: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...
Out of curiosity: when did you start to take the first serious steps in this direction?
Re: The beginning of Git supporting other hash algorithms
#18Why don't you ask Linus, I'm sure he will calmly and respectfully explain the answer while apologizing for the trouble :)
That's a pretty unwarranted response which contributes nothing to the discussion.
Re: The beginning of Git supporting other hash algorithms
#19Earlier quoted context omitted.
Backwards compat requires that both old and new hashes work at the same time. A simple typedef is unlikely to handle all the semantics and space needed for such a change... It is often hard to generalize when N=1. Now that the N=1 use case is established and we are moving towards N=2, it is painfully obvious to all that a better abstraction is needed. Typedef or no, we would still need a full audit of the code to fin…
Perhaps you haven't read Linus' comments where he stated (more than a decade ago) that the usage of SHA1 here isn't for "security"? (Hint: that's why GPG signing commits is an option.)
When you GPG sign a commit, you just GPG sign its hash, you're not signing its diff alongside it.
Re: The beginning of Git supporting other hash algorithms
#20Why don't you ask Linus, I'm sure he will calmly and respectfully explain the answer while apologizing for the trouble :)
I feel like Linus (and others) have earned the right to be assholes on the mailing lists. He's demonstrated good judgement and made huge contributions, if he doesn't feel the need to be nice i don't think he should have to.