git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Derrick Stolee <stolee@gmail.com>,
	Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] setup: warn about un-enabled extensions
Date: Tue, 14 Jul 2020 08:27:21 -0700	[thread overview]
Message-ID: <xmqqzh82ktgm.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2007141420300.52@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Tue, 14 Jul 2020 14:21:30 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> If you don't mind, I was already going to squash Junio's commit into
>> mine (almost completely replacing mine) but I could add a small
>> commit on top that provides the following improvement to the error
>> message:
>
> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing
> users in the same was as v2.28.0-rc0 confused me.

In a nearby thread, Jonathan Nieder raised an interesting approach
to avoid confusing users, which I think (if I am reading him
correctly) makes sense (cf. <20200714040616.GA2208896@google.com>)

What if we accept the extensions the code before the topic in
question that was merged in -rc0 introduced the "confusion" accepts
even in v0?  If we see extensions other than those handpicked and
grandfathered ones (which are presumably the ones we add later and
support in v1 and later repository versions) in a v0 repository, we
keep ignoring.  Also we'd loosen the overly strict code that
prevents upgrading from v0 to v1 in the presence of any extensions
in -rc0, so that the grandfathered ones will not prevent the
upgrading.

The original reasoning behind the strict check was because the users
could have used extensions.frotz for their own use with their own
meaning, trusting that Git would simply ignore it, and an upgrade to
later version in which Git uses extensions.frotz for a purpose that
is unrelated to the reason why these users used would just break the
repository.  

But the ones that were (accidentally) honored in v0 couldn't have
been used by the users for the purposes other than how Git would use
them anyway, so there is no point to make them prevent the upgrade
of the repository version from v0 to v1.

At least, that is how I understood the world would look like in
Jonathan's "different endgame".

What do you three (Dscho, Derrick and Jonathan) think?  



> Thanks,
> Dscho
>
>>
>> diff --git a/builtin/config.c b/builtin/config.c
>> index 5e39f618854..b5de7982a93 100644
>> --- a/builtin/config.c
>> +++ b/builtin/config.c
>> @@ -678,8 +678,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)
>>                 else if (worktrees[0] && worktrees[1])
>>                         die(_("--worktree cannot be used with multiple "
>>                               "working trees unless the config\n"
>> -                             "extension worktreeConfig is enabled. "
>> -                             "Please read \"CONFIGURATION FILE\"\n"
>> +                             "extension worktreeConfig is enabled "
>> +                             "and core.repositoryFormatVersion is at least\n"
>> +                             "1. Please read \"CONFIGURATION FILE\""
>>                               "section in \"git help worktree\" for details"));
>>                 else
>>                         given_config_source.file = git_pathdup("config");
>>
>> Thanks,
>> -Stolee
>>
>>

  reply	other threads:[~2020-07-14 15:27 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 21:55 [PATCH] setup: warn about un-enabled extensions Johannes Schindelin via GitGitGadget
2020-07-13 22:48 ` Junio C Hamano
2020-07-14  0:24 ` Derrick Stolee
2020-07-14 12:21   ` Johannes Schindelin
2020-07-14 15:27     ` Junio C Hamano [this message]
2020-07-14 15:40       ` Derrick Stolee
2020-07-14 20:30         ` Johannes Schindelin
2020-07-14 20:47           ` Junio C Hamano
2020-07-15 16:09       ` Junio C Hamano
2020-07-15 17:01         ` Junio C Hamano
2020-07-15 18:00           ` Derrick Stolee
2020-07-15 18:09             ` Junio C Hamano
2020-07-15 18:40               ` Derrick Stolee
2020-07-15 19:16                 ` Johannes Schindelin
2020-07-15 18:15             ` Junio C Hamano
2020-07-15 19:21               ` Johannes Schindelin
2020-07-15 18:20         ` Jonathan Nieder
2020-07-16  2:06           ` Junio C Hamano
2020-07-16  6:20         ` [PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions) Jonathan Nieder
2020-07-16  6:24           ` [PATCH 1/2] Revert "check_repository_format_gently(): refuse extensions for old repositories" Jonathan Nieder
2020-07-16 10:56             ` Jeff King
2020-07-16  6:28           ` [PATCH 2/2] repository: allow repository format upgrade with extensions Jonathan Nieder
2020-07-16  7:01             ` Junio C Hamano
2020-07-16 11:00               ` Jeff King
2020-07-16 12:25                 ` Jeff King
2020-07-16 12:53                   ` Derrick Stolee
2020-07-16 16:32                   ` Junio C Hamano
2020-07-16 16:53                     ` Jeff King
2020-07-16 20:27                     ` Junio C Hamano
2020-07-16 16:49                   ` Junio C Hamano
2020-07-16 16:56                     ` Jeff King
2020-07-16 16:10                 ` Junio C Hamano
2020-07-16 22:37                   ` Jonathan Nieder
2020-07-16 23:50                     ` Junio C Hamano
2020-07-17 15:27                       ` Jeff King
2020-07-17 17:07                         ` Junio C Hamano
2020-07-17 15:22                     ` Jeff King
2020-07-16  8:13           ` [PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions) Johannes Schindelin
2020-07-16 12:17             ` Derrick Stolee

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=xmqqzh82ktgm.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=stolee@gmail.com \
    /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).