git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>, Taylor Blau <me@ttaylorr.com>,
	Matheus Tavares <matheus.bernardino@usp.br>
Subject: Re: [PATCH v2] builtin/clone: avoid failure with GIT_DEFAULT_HASH
Date: Mon, 14 Sep 2020 21:31:14 -0700	[thread overview]
Message-ID: <xmqq8sdb1x0t.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200915015845.4149976-1-sandals@crustytoothpaste.net> (brian m. carlson's message of "Tue, 15 Sep 2020 01:58:45 +0000")

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

> If a user is cloning a SHA-1 repository with GIT_DEFAULT_HASH set to
> "sha256", then we can end up with a repository where the repository
> format version is 0 but the extensions.objectformat key is set to
> "sha256".  This is both wrong (the user has a SHA-1 repository) and
> nonfunctional (because the extension cannot be used in a v0 repository).
>
> This happens because in a clone, we initially set up the repository, and
> then change its algorithm based on what the remote side tells us it's
> using.  We've initially set up the repository as SHA-256 in this case,
> and then later on reset the repository version without clearing the
> extension.
>
> We could just always set the extension in this case, but that would mean
> that our SHA-1 repositories weren't compatible with older Git versions,
> even though there's no reason why they shouldn't be.  And we also don't
> want to initialize the repository as SHA-1 initially, since that means
> if we're cloning an empty repository, we'll have failed to honor the
> GIT_DEFAULT_HASH variable and will end up with a SHA-1 repository, not a
> SHA-256 repository.
>
> Neither of those are appealing, so let's tell the repository
> initialization code if we're doing a reinit like this, and if so, to
> clear the extension if we're using SHA-1.  This makes sure we produce a
> valid and functional repository and doesn't break any of our other use
> cases.
>
> Reported-by: Matheus Tavares <matheus.bernardino@usp.br>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> Changes since v1:
> * Use git_config_set_gently to make things work with SHA-1 repos as well
>   as SHA-256 repos.

Hmph, the reason why v1's bug weren't caught was because it was only
tested with GIT_TEST_DEFAULT_HASH=sha256, right?  I am wondering if
adding two new tests that run the same end-user scenario except
for the choice of hash algorithms would be a good way to ensure this
will stay fixed.  Am I mistaken?

Thanks anyway for a quick turnaround.

> Diff-intervalle contre v1 :
> 1:  32d3357460 ! 1:  1becbbbb50 builtin/clone: avoid failure with GIT_DEFAULT_HASH
>     @@ builtin/init-db.c: void initialize_repository_version(int hash_algo)
>       		git_config_set("extensions.objectformat",
>       			       hash_algos[hash_algo].name);
>      +	else if (reinit)
>     -+		git_config_set("extensions.objectformat", NULL);
>     ++		git_config_set_gently("extensions.objectformat", NULL);
>       }
>       
>       static int create_default_files(const char *template_path,
>
>  builtin/clone.c   |  2 +-
>  builtin/init-db.c |  6 ++++--
>  cache.h           |  2 +-
>  t/t5601-clone.sh  | 10 ++++++++++
>  4 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index b087ee40c2..925a2e3dd6 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -1235,7 +1235,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>  		 * Now that we know what algorithm the remote side is using,
>  		 * let's set ours to the same thing.
>  		 */
> -		initialize_repository_version(hash_algo);
> +		initialize_repository_version(hash_algo, 1);
>  		repo_set_hash_algo(the_repository, hash_algo);
>  
>  		mapped_refs = wanted_peer_refs(refs, &remote->fetch);
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index cd3e760541..01bc648d41 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -179,7 +179,7 @@ static int needs_work_tree_config(const char *git_dir, const char *work_tree)
>  	return 1;
>  }
>  
> -void initialize_repository_version(int hash_algo)
> +void initialize_repository_version(int hash_algo, int reinit)
>  {
>  	char repo_version_string[10];
>  	int repo_version = GIT_REPO_VERSION;
> @@ -195,6 +195,8 @@ void initialize_repository_version(int hash_algo)
>  	if (hash_algo != GIT_HASH_SHA1)
>  		git_config_set("extensions.objectformat",
>  			       hash_algos[hash_algo].name);
> +	else if (reinit)
> +		git_config_set_gently("extensions.objectformat", NULL);
>  }
>  
>  static int create_default_files(const char *template_path,
> @@ -277,7 +279,7 @@ static int create_default_files(const char *template_path,
>  		free(ref);
>  	}
>  
> -	initialize_repository_version(fmt->hash_algo);
> +	initialize_repository_version(fmt->hash_algo, 0);
>  
>  	/* Check filemode trustability */
>  	path = git_path_buf(&buf, "config");
> diff --git a/cache.h b/cache.h
> index cee8aa5dc3..c0072d43b1 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -629,7 +629,7 @@ int path_inside_repo(const char *prefix, const char *path);
>  int init_db(const char *git_dir, const char *real_git_dir,
>  	    const char *template_dir, int hash_algo,
>  	    const char *initial_branch, unsigned int flags);
> -void initialize_repository_version(int hash_algo);
> +void initialize_repository_version(int hash_algo, int reinit);
>  
>  void sanitize_stdfds(void);
>  int daemonize(void);
> diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
> index 15fb64c18d..570d989795 100755
> --- a/t/t5601-clone.sh
> +++ b/t/t5601-clone.sh
> @@ -631,6 +631,16 @@ test_expect_success CASE_INSENSITIVE_FS 'colliding file detection' '
>  	test_i18ngrep "the following paths have collided" icasefs/warning
>  '
>  
> +test_expect_success 'clone with GIT_DEFAULT_HASH' '
> +	(
> +		sane_unset GIT_DEFAULT_HASH &&
> +		git init test
> +	) &&
> +	test_commit -C test foo &&
> +	git clone test test-clone &&
> +	git -C test-clone status
> +'
> +
>  partial_clone_server () {
>  	       SERVER="$1" &&
>  

  reply	other threads:[~2020-09-15  4:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 15:17 Posible bug with GIT_DEFAULT_HASH during clone Matheus Tavares
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 [this message]
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=xmqq8sdb1x0t.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=matheus.bernardino@usp.br \
    --cc=me@ttaylorr.com \
    --cc=sandals@crustytoothpaste.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).