Re: Posible bug with GIT_DEFAULT_HASH during clone

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 11, 2020, 23:20 UTC
Message-ID: <20200911232005.GM241078@camp.crustytoothpaste.net>
In-Reply-To: <20200911151717.43475-1-matheus.bernardino@usp.br>

On 2020-09-11 at 15:17:17, Matheus Tavares wrote:

Show 38 quoted lines

> Hi, everyone
> 
> Documentation/git.txt mentions that GIT_DEFAULT_HASH is ignored during
> clone, but I think it may not be *totally* ignored, sometimes leaving
> the config file on the cloned repo in an inconsistent state.
> 
> To reproduce this (tested with current `master` and `seen`):
> 
> git init test
> echo F>test/F
> git -C test add F
> git -C test commit -m F
> export GIT_DEFAULT_HASH=sha256
> git clone test test-clone
> git -C test-clone status
> 
> Which outputs:
> fatal: repo version is 0, but v1-only extensions found:
>         objectformat
> 
> From what I could see under gdb, the steps leading to this are:
> 
> - First, this call chain gets the GIT_DEFAULT_HASH value:
>   cmd_clone() > init_db() > validate_hash_algorithm().
> 
> - Then, init_db() calls create_default_files(), which calls
>   initialize_repository_version() with GIT_HASH_SHA256, setting these
>   configs:
>   * extensions.objectFormat=sha256
>   * core.repositoryFormatVersion=1
> 
> - Finally, cmd_clone() later uses the return of
>   transport_get_hash_algo() to call initialize_repository_version()
>   again, but with GIT_HASH_SHA1, setting:
>   * core.repositoryFormatVersion=0
> 
> So we end up with the repository format version as 0 but the
> objectFormat extension is present.

Thanks for the bug report and reproduction steps. There are a couple possibilities here:

* First, we just initialize the repository with SHA-1.  When I saw this,
  I tried that, but it breaks anytime we have an empty repository (and
  with partial clone, apparently).  So I don't think this is going to
  work.
* We take a reinitialize flag in initialize_repository_version and then
  set the algorithm to "sha1".  This is extremely easy, but it also
  poses some compatibility problems, because older versions of Git won't
  handle this configuration.
* We take a reinitialize flag and clear the value, which seems to be the
  best way forward.  I'll verify that this doesn't pose any unforeseen
  problems elsewhere in the testsuite and then send a patch.

-- 
brian m. carlson: Houston, Texas, US