Re: Posible bug with GIT_DEFAULT_HASH during clone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-09-11 at 15:17:17, Matheus Tavares wrote:
> 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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux