From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Bert Wesarg <bert.wesarg@googlemail.com>
Subject: Re: [PATCH 1/2] remote: add camel-cased *.tagOpt key, like clone
Date: Wed, 24 Feb 2021 19:02:19 -0800 [thread overview]
Message-ID: <xmqq1rd4yhms.fsf@gitster.g> (raw)
In-Reply-To: <20210225012117.17331-1-avarab@gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Thu, 25 Feb 2021 02:21:16 +0100")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Change "git remote add" so that it adds a *.tagOpt key, and not the
> lower-cased *.tagopt on "git remote add --no-tags", just as "git clone
> --no-tags" would do.
>
> This doesn't matter for anything that reads the config. It's just
> prettier if we write config keys in their documented camelCase form to
> user-readable config files.
>
> When I added support for "clone -no-tags" in 0dab2468ee5 (clone: add a
> --no-tags option to clone without tags, 2017-04-26) I made it use
> the *.tagOpt form, but the older "git remote add" added in
> 111fb858654 (remote add: add a --[no-]tags option, 2010-04-20) has
> been using *.tagopt all this time.
>
> It's easy enough to add a test for this, so let's do that. We can't
> use "git config -l" there, because it'll normalize the keys to their
> lower-cased form. Let's add the test for "git clone" too for good
> measure, not just to the "git remote" codepath we're fixing.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>
> I also noticed that we write e.g. init.objectformat instead of
> init.objectFormat, and core.logallrefupdates etc. If anyone's got an
> even even worse case of OCD there's an interesting #leftoverbits
> project there of scouring the code for more cases of this sort of
> thing...
>
> builtin/remote.c | 2 +-
> t/t5505-remote.sh | 1 +
> t/t5612-clone-refspec.sh | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index d11a5589e49..f286ae97538 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -221,7 +221,7 @@ static int add(int argc, const char **argv)
>
> if (fetch_tags != TAGS_DEFAULT) {
> strbuf_reset(&buf);
> - strbuf_addf(&buf, "remote.%s.tagopt", name);
> + strbuf_addf(&buf, "remote.%s.tagOpt", name);
Good find.
A general rule for a name used to refer to a configuration variable
the C code ought to be
- if it is used to match what the system gave us, make sure we use
all lowercase for the first and the last component and match with
strcmp(), not with strcasecmp().
- if it is used to update, make sure we use the canonical spelling,
if only for the documentation value.
> diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
> index 045398b94e6..2a7b5cd00a0 100755
> --- a/t/t5505-remote.sh
> +++ b/t/t5505-remote.sh
> @@ -594,6 +594,7 @@ test_expect_success 'add --no-tags' '
> cd add-no-tags &&
> git init &&
> git remote add -f --no-tags origin ../one &&
> + grep tagOpt .git/config &&
> git tag -l some-tag >../test/output &&
> git tag -l foobar-tag >../test/output &&
> git config remote.origin.tagopt >>../test/output
> diff --git a/t/t5612-clone-refspec.sh b/t/t5612-clone-refspec.sh
> index 6a6af7449ca..3126cfd7e9d 100755
> --- a/t/t5612-clone-refspec.sh
> +++ b/t/t5612-clone-refspec.sh
> @@ -97,6 +97,7 @@ test_expect_success 'by default no tags will be kept updated' '
> test_expect_success 'clone with --no-tags' '
> (
> cd dir_all_no_tags &&
> + grep tagOpt .git/config &&
> git fetch &&
> git for-each-ref refs/tags >../actual
> ) &&
next prev parent reply other threads:[~2021-02-25 3:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 1:21 [PATCH 1/2] remote: add camel-cased *.tagOpt key, like clone Ævar Arnfjörð Bjarmason
2021-02-25 1:21 ` [PATCH 2/2] remote: write camel-cased *.pushRemote on rename Ævar Arnfjörð Bjarmason
2021-02-25 3:17 ` Junio C Hamano
2021-03-18 11:22 ` Bert Wesarg
2021-02-25 3:02 ` Junio C Hamano [this message]
2021-02-25 3:16 ` [PATCH 1/2] remote: add camel-cased *.tagOpt key, like clone Junio C Hamano
2021-02-25 19:47 ` Ævar Arnfjörð Bjarmason
2021-02-25 20:00 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1rd4yhms.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=bert.wesarg@googlemail.com \
--cc=git@vger.kernel.org \
/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).