git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Matheus Tavares <matheus.bernardino@usp.br>
To: git@vger.kernel.org
Cc: sandals@crustytoothpaste.net, martin.agren@gmail.com
Subject: Posible bug with GIT_DEFAULT_HASH during clone
Date: Fri, 11 Sep 2020 12:17:17 -0300	[thread overview]
Message-ID: <20200911151717.43475-1-matheus.bernardino@usp.br> (raw)

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,
Matheus


             reply	other threads:[~2020-09-11 16:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 15:17 Matheus Tavares [this message]
2020-09-11 23:20 ` brian m. carlson
2020-09-11 23:38 ` [PATCH] builtin/clone: avoid failure with GIT_DEFAULT_HASH brian m. carlson
2020-09-12  3:24   ` Taylor Blau
2020-09-12 19:52     ` brian m. carlson
2020-09-14 21:37       ` Junio C Hamano
2020-09-14 21:44         ` Junio C Hamano
2020-09-15  1:32           ` brian m. carlson
2020-09-15  1:58   ` [PATCH v2] " brian m. carlson
2020-09-15  4:31     ` Junio C Hamano
2020-09-15 22:51       ` brian m. carlson
2020-09-20 22:35   ` [PATCH v3] " brian m. carlson
2020-09-21  4:27     ` Junio C Hamano
2020-09-22  9:17       ` brian m. carlson
2020-09-22 16:27         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200911151717.43475-1-matheus.bernardino@usp.br \
    --to=matheus.bernardino@usp.br \
    --cc=git@vger.kernel.org \
    --cc=martin.agren@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    --subject='Re: Posible bug with GIT_DEFAULT_HASH during clone' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).