"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > We have a large variety of data formats and protocols where no hash > algorithm was defined and the default was assumed to always be SHA-1. > Instead of explicitly stating SHA-1, let's use the constant to represent > the original hash algorithm (which is still SHA-1) so that it's clear > for documentary purposes that it's a legacy fallback option and not an > intentional choice to use SHA-1. > > Signed-off-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> > --- > builtin/receive-pack.c | 2 +- > bundle.c | 4 ++-- > connect.c | 6 +++--- > fetch-pack.c | 2 +- > pkt-line.c | 2 +- > remote-curl.c | 2 +- > serve.c | 2 +- > setup.c | 4 ++-- > transport.c | 2 +- > 9 files changed, 13 insertions(+), 13 deletions(-) I earlier expressed my puzzlement, but this step shows how GIT_HASH_ORIGINAL may make sense as a transitional measure, letting us tell between "This place in the code uses GIT_HASH_SHA1 simply because we haven't examined and inspected it for the purpose of allowing us to eventually switch the default" and "This place in the code we determined need to keep using SHA1 even when the default is different". If that is what is going on, after the whole-code transition finishes, we would want to rename _ORIGINAL back to _SHA1 for readability, as in such a future, developers should not have to remember that we originally used SHA-1. If we call use a name with SHA-1 in it (e.g., GIT_HASH_MUST_BE_SHA1) from the beginning, perhaps we do not have to rename _ORIGINAL later?
