git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: newren@gmail.com, delphij@google.com, peff@peff.net,
	Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: [PATCH] setup: warn if extensions exist on old format
Date: Mon, 13 Jul 2020 19:20:51 +0000	[thread overview]
Message-ID: <pull.674.git.1594668051847.gitgitgadget@gmail.com> (raw)

From: Derrick Stolee <dstolee@microsoft.com>

Prior to 14c7fa269e4 (check_repository_format_gently(): refuse extensions
for old repositories, 2020-06-05), Git was honoring configured
extensions, even if core.repositoryFormatVersion was 0 (or unset). This
was incorrect, and is now fixed.

The issue now is that users who relied on that previously bad behavior
will upgrade to the next version of Git and suddently be in a bad
situation. In particular, users of the 'git sparse-checkout' builting
will rely on the extensions.worktreeConfig for the core.sparseCheckout
and core.sparseCheckoutCone config options. Without that extension,
these users will suddenly have repositories stop acting like a sparse
repo.

What is worse is that a user will be confronted with the following
error if they try to run 'git sparse-checkout init' again:

	warning: unable to upgrade repository format from 0 to 1

This is because the logic in 14c7fa269e4 refuses to upgrae repos when
the version is unset but extensions exist.

While it is important to correct this improper behavior, create a
warning so users in this situation can correct themselves without too
much guesswork. By creating a warning in
check_repository_format_gently(), we can alert the user if they have a
ocnfigured extension but not a configured repository version.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---
    setup: warn if extensions exist on old format
    
    This is based on xl/upgrade-repo-format.
    
    Can this be considered for v2.28.0-rc1? I think this is an important
    shift in behavior that will disrupt many users if they upgrade without
    it!
    
    If not this warning or change, then how else can we help users who are
    in this situation? How can we save those who adopted the sparse-checkout
    builtin in recent versions from terrible post-upgrade headaches?
    
    Thanks, -Stolee

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-674%2Fderrickstolee%2Fsparse-checkout-warning-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-674/derrickstolee/sparse-checkout-warning-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/674

 setup.c                            | 5 +++++
 t/t1091-sparse-checkout-builtin.sh | 9 +++++++++
 2 files changed, 14 insertions(+)

diff --git a/setup.c b/setup.c
index eb066db6d8..6ff6c54d39 100644
--- a/setup.c
+++ b/setup.c
@@ -542,6 +542,11 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
 		}
 	}
 
+	if (candidate->version == 0 && candidate->has_extensions) {
+		warning(_("some extensions are enabled, but core.repositoryFormatVersion=0"));
+		warning(_("if you intended to use extensions, run 'git config core.repositoryFormatVersion 1'"));
+	}
+
 	return 0;
 }
 
diff --git a/t/t1091-sparse-checkout-builtin.sh b/t/t1091-sparse-checkout-builtin.sh
index 88cdde255c..d249428f44 100755
--- a/t/t1091-sparse-checkout-builtin.sh
+++ b/t/t1091-sparse-checkout-builtin.sh
@@ -68,6 +68,15 @@ test_expect_success 'git sparse-checkout init' '
 	check_files repo a
 '
 
+test_expect_success 'warning about core.repositoryFormatVersion' '
+	test_when_finished git -C repo config core.repositoryFormatVersion 1 &&
+	git -C repo status 2>err &&
+	test_must_be_empty err &&
+	git -C repo config --local core.repositoryFormatVersion 0 &&
+	git -C repo status 2>err &&
+	test_i18ngrep "some extensions are enabled, but core.repositoryFormatVersion=0" err
+'
+
 test_expect_success 'git sparse-checkout list after init' '
 	git -C repo sparse-checkout list >actual &&
 	cat >expect <<-\EOF &&

base-commit: 14c7fa269e42df4133edd9ae7763b678ed6594cd
-- 
gitgitgadget

             reply	other threads:[~2020-07-13 19:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 19:20 Derrick Stolee via GitGitGadget [this message]
2020-07-13 19:34 ` [PATCH] setup: warn if extensions exist on old format Taylor Blau
2020-07-13 19:41   ` Derrick Stolee
2020-07-13 19:36 ` Junio C Hamano
2020-07-13 20:00   ` Junio C Hamano
2020-07-13 20:18     ` [PATCH] setup: tweak upgrade policy to grandfather worktreeconfig Junio C Hamano
2020-07-13 20:46       ` Derrick Stolee
2020-07-13 21:45         ` Junio C Hamano
2020-07-14  4:06         ` Jonathan Nieder
2020-07-14  4:27           ` Junio C Hamano
2020-07-14  1:26 ` [PATCH v2 0/2] setup: warn if extensions exist on old format Derrick Stolee via GitGitGadget
2020-07-14  1:26   ` [PATCH v2 1/2] setup: tweak upgrade policy to grandfather worktreeconfig Derrick Stolee via GitGitGadget
2020-07-14 20:22     ` Johannes Schindelin
2020-07-14  1:26   ` [PATCH v2 2/2] config: provide extra detail about worktree config Derrick Stolee via GitGitGadget
2020-07-14 20:24   ` [PATCH v2 0/2] setup: warn if extensions exist on old format Johannes Schindelin

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

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

  git send-email \
    --in-reply-to=pull.674.git.1594668051847.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=delphij@google.com \
    --cc=derrickstolee@github.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=peff@peff.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.
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 NNTP newsgroup(s).