The beginning of Git supporting other hash algorithms
1–10 of 128 posts
Re: The beginning of Git supporting other hash algorithms
#2Is there some explainer on how the support will look like in the end? I'm curious to know how multiple hash algorithms will be supported in parallel.
Re: The beginning of Git supporting other hash algorithms
#3Is there some explainer on how the support will look like in the end? I'm curious to know how multiple hash algorithms will be supported in parallel.
Probably newer versions will commit only using a new hash algorithm, while completely able to deal with the old one
Re: The beginning of Git supporting other hash algorithms
#4Is there some explainer on how the support will look like in the end? I'm curious to know how multiple hash algorithms will be supported in parallel.
Probably newer versions will commit only using a new hash algorithm, while completely able to deal with the old one
Can it really be that simple though? If you are using a newer version of Git on your repo which is committing only with the newer
hash and I try to clone your repo with an older version I will be unable to do so. I guess maybe that's acceptable though?
Re: The beginning of Git supporting other hash algorithms
#5The commit on git.kernel.org: https://git.kernel.org/pub/scm/git/git.git/commit/?id=e1fae9...
Re: The beginning of Git supporting other hash algorithms
#6struct object_id was introduced in this commit, in 2015:
https://git.kernel.org/pub/scm/git/git.git/commit/?id=5f7817...
So this change doesn't do much for now. Good to see, though.
Re: The beginning of Git supporting other hash algorithms
#7Earlier quoted context omitted.
Probably newer versions will commit only using a new hash algorithm, while completely able to deal with the old one
Can it really be that simple though? If you are using a newer version of Git on your repo which is committing only with the newer hash and I try to clone your repo with an older version I will be unable to do so. I guess maybe that's acceptable though?
Probably not. I imagine the deprecation period for this change will be measured in years.
Re: The beginning of Git supporting other hash algorithms
#8Earlier quoted context omitted.
Probably newer versions will commit only using a new hash algorithm, while completely able to deal with the old one
Can it really be that simple though? If you are using a newer version of Git on your repo which is committing only with the newer hash and I try to clone your repo with an older version I will be unable to do so. I guess maybe that's acceptable though?
I think backwards incompatibility would be acceptable. Add read support for the new format to git, but then don't have widespread repositories using the new format until some period of time later. By the time they do become commonplace, everyone should already be running a version of git supporting them. It's not exactly hard to upgrade git in most situations anyway, just a simple invocation of:
$ sudo $PKG_MGR upgrade gitRe: The beginning of Git supporting other hash algorithms
#9I'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...
Re: The beginning of Git supporting other hash algorithms
#10Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.