Re: [PATCH v2] setup: fix hash algorithm detection

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> Our current hash algorithm selection code has a few different problems.
> First, we do not actually default to GIT_HASH_DEFAULT.  Second, if we
> have an algorithm chosen by init.defaultObjectFormat and we re-init a
> repository, we will change the hash algorithm, which is very much not
> desired.
>
> Let's restructure this code slightly.  First, if an algorithm was
> selected on the command line, assume that's what the user wanted.
> Otherwise, the other options should only be chosen if our repository
> doesn't exist (that is, repo_fmt->version is -1) or it's specifically
> detected as having no hash algorithm.  In that case, first use the
> environment, then the config, and finally, the default algorithm.
>
> Then, if the algorithm does not match the repository, complain loudly
> and refuse to reinitialize the repository with a different hash
> algorithm.
>
> With this change, we will choose SHA-256 in breaking changes mode and in
> Git 3.0, which is what we want.  Add several tests to cover this case
> and several others discovered along the way.
>
> Reported-by: Adam Dinwoodie <adam@dinwoodie.org>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  setup.c         | 22 +++++++++++--------
>  t/t0001-init.sh | 58 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 71 insertions(+), 9 deletions(-)

I was somehow expecting a patch that would apply cleanly both to the
maintenance track and to the 2.98 but that is totally unnecessary,
as it does not make any sense to build and use the maintenance track
with the WITH_BREAKING_CHANGES option ;-) The point of the
WITH_BREAKING_CHANGES option is to make sure we have a test vehicle
to try out something that is close enough to "Git 3.0" long before
we release one.

And the updated code structure looks much simpler and more
straightforward.

Will replace.

Thanks.