From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, joe.drew@indexexchange.com, peff@peff.net,
gitster@pobox.com
Subject: Re: [PATCH 2/2] refs/files: handle F/D conflicts in case-insensitive FS
Date: Wed, 3 Sep 2025 09:40:42 +0200 [thread overview]
Message-ID: <aLfw-peLY8NEKSZd@pks.im> (raw)
In-Reply-To: <20250902-587-git-fetch-1-fails-fetches-on-case-insensitive-repositories-v1-2-35e69bbb507d@gmail.com>
On Tue, Sep 02, 2025 at 10:34:26AM +0200, Karthik Nayak wrote:
> Similar to the previous commit, when using the files-backend on
> case-insensitive filesystems, there is possibility of hitting F/D
> conflicts when creating references within a single transaction, such as:
>
> - 'refs/heads/foo'
> - 'refs/heads/Foo/bar'
Great, I wanted to ask about this scenario.
> Ideally such conflicts are caught in `refs_verify_refnames_available()`
> which is responsible for checking F/D conflicts within a given
> transaction. This utility function is shared across the reference
> backends. As such, it doesn't consider the issues of using a
> case-insensitive, which only affects the files-backend.
>
> While one solution would be to make the function aware of such issues.
> This feels like leaking implementation details of file-backend specific
> issues into the utility function. So opt for the more simpler option, of
> lowercasing all references sent to this function when on a
> case-insensitive filesystem and operating on the files-backend.
>
> To do this, simply use a `struct strbuf` to convert the refname to a
> lower case and append it to the list of refnames to be checked. Since we
> use a `struct strbuf` and the memory is cleared right after, make sure
> that the string list duplicates all provided string.
>
> Without this change, the user would simply be left with a repository
> with '.lock' files which were created in the 'prepare' phase of the
> transaction, as the 'commit' phase would simply abort and not do the
> necessary cleanup.
Oh, that's a clever hack. Does this also work for the case where we have
preexisting refs already that differ only in casing? I guess it should
given that the lookups we perform should yield those refs regardless of
their casing.
In any case, if we don't already have such a test it would be great to
also verify that this works as expected.
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 9f58ea4858..466cdfe121 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -869,8 +869,23 @@ static enum ref_transaction_error lock_raw_ref(struct files_ref_store *refs,
> * If the ref did not exist and we are creating it, we have to
> * make sure there is no existing packed ref that conflicts
> * with refname. This check is deferred so that we can batch it.
> + *
> + * For case-insensitive filesystems, we should also check for F/D
> + * conflicts between 'foo' and 'Foo/bar'. So let's lowercase
> + * the refname.
> */
> - item = string_list_append(refnames_to_check, refname);
> + if (ignore_case) {
> + struct strbuf lower = STRBUF_INIT;
> +
> + strbuf_addstr(&lower, refname);
> + strbuf_tolower(&lower);
> +
> + item = string_list_append(refnames_to_check, lower.buf);
> + strbuf_release(&lower);
Can we use `string_list_append_nodup()` together with `strbuf_detach()`
here to avoid one memory allocation?
> + } else {
> + item = string_list_append(refnames_to_check, refname);
> + }
> +
> item->util = xmalloc(sizeof(update_idx));
> memcpy(item->util, &update_idx, sizeof(update_idx));
> }
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 57f60da81b..84dc68e5f3 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -53,6 +53,12 @@ test_expect_success "clone and setup child repos" '
> cd case_sensitive &&
> git branch branch1 &&
> git branch bRanch1
> + ) &&
> + git clone --ref-format=reftable . case_sensitive_fd &&
> + (
> + cd case_sensitive_fd &&
> + git branch foo/bar &&
> + git branch Foo
> )
> '
>
Nice idea to use the reftable format here.
> @@ -1546,6 +1552,20 @@ test_expect_success CASE_INSENSITIVE_FS,REFFILES 'existing references in a case
> )
> '
>
> +test_expect_success CASE_INSENSITIVE_FS,REFFILES 'F/D conflict on case insensitive filesystem' '
> + test_when_finished rm -rf case_insensitive &&
> + (
> + git init --bare case_insensitive &&
> + cd case_insensitive &&
> + git remote add origin -- ../case_sensitive_fd &&
> + test_must_fail git fetch -f origin "refs/heads/*:refs/heads/*" 2>err &&
> + test_grep "failed: refname conflict" err &&
> + git rev-parse refs/heads/main >expect &&
> + git rev-parse refs/heads/foo/bar >actual &&
> + test_cmp expect actual
> + )
> +'
Okay, so we again only end up with one of these references, which is the
best we can do.
atrick
next prev parent reply other threads:[~2025-09-03 7:40 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 8:34 [PATCH 0/2] refs/files: fix issues with git-fetch on case-insensitive FS Karthik Nayak
2025-09-02 8:34 ` [PATCH 1/2] refs/files: use correct error type when locking fails Karthik Nayak
2025-09-02 21:22 ` Chris Torek
2025-09-04 20:24 ` Karthik Nayak
2025-09-03 7:40 ` Patrick Steinhardt
2025-09-03 10:38 ` Karthik Nayak
2025-09-03 11:48 ` Patrick Steinhardt
2025-09-03 16:53 ` Junio C Hamano
2025-09-02 8:34 ` [PATCH 2/2] refs/files: handle F/D conflicts in case-insensitive FS Karthik Nayak
2025-09-03 7:40 ` Patrick Steinhardt [this message]
2025-09-08 7:27 ` Karthik Nayak
2025-09-03 18:16 ` Junio C Hamano
2025-09-04 22:43 ` Junio C Hamano
2025-09-08 9:27 ` Karthik Nayak
2025-09-08 9:29 ` Karthik Nayak
2025-09-08 12:37 ` [PATCH v2 0/4] refs/files: fix issues with git-fetch on " Karthik Nayak
2025-09-08 12:37 ` [PATCH v2 1/4] refs/files: catch conflicts on case-insensitive file-systems Karthik Nayak
2025-09-09 7:09 ` Patrick Steinhardt
2025-09-11 9:35 ` Karthik Nayak
2025-09-08 12:37 ` [PATCH v2 2/4] refs/files: use correct error type when lock exists Karthik Nayak
2025-09-09 7:10 ` Patrick Steinhardt
2025-09-11 10:14 ` Karthik Nayak
2025-09-08 12:37 ` [PATCH v2 3/4] refs/files: handle F/D conflicts in case-insensitive FS Karthik Nayak
2025-09-08 12:37 ` [PATCH v2 4/4] refs/files: handle D/F conflicts during locking Karthik Nayak
2025-09-09 7:10 ` Patrick Steinhardt
2025-09-12 11:53 ` Karthik Nayak
2025-09-13 20:54 ` [PATCH v3 0/4] refs/files: fix issues with git-fetch on case-insensitive FS Karthik Nayak
2025-09-13 20:54 ` [PATCH v3 1/4] refs/files: catch conflicts on case-insensitive file-systems Karthik Nayak
2025-09-16 21:13 ` Justin Tobler
2025-09-17 7:33 ` Karthik Nayak
2025-09-17 15:30 ` Karthik Nayak
2025-09-17 15:34 ` Justin Tobler
2025-09-13 20:54 ` [PATCH v3 2/4] refs/files: use correct error type when lock exists Karthik Nayak
2025-09-16 7:51 ` Patrick Steinhardt
2025-09-17 7:37 ` Karthik Nayak
2025-09-16 21:31 ` Justin Tobler
2025-09-17 7:39 ` Karthik Nayak
2025-09-13 20:54 ` [PATCH v3 3/4] refs/files: handle F/D conflicts in case-insensitive FS Karthik Nayak
2025-09-16 21:52 ` Justin Tobler
2025-09-17 7:42 ` Karthik Nayak
2025-09-13 20:54 ` [PATCH v3 4/4] refs/files: handle D/F conflicts during locking Karthik Nayak
2025-09-16 21:53 ` [PATCH v3 0/4] refs/files: fix issues with git-fetch on case-insensitive FS Junio C Hamano
2025-09-17 7:45 ` Karthik Nayak
2025-09-17 14:27 ` Toon Claes
2025-09-17 15:24 ` Karthik Nayak
2025-09-17 17:04 ` Junio C Hamano
2025-09-17 20:40 ` Karthik Nayak
2025-09-17 14:34 ` Junio C Hamano
2025-09-17 15:25 ` Karthik Nayak
2025-09-17 15:25 ` [PATCH v4 " Karthik Nayak
2025-09-17 15:25 ` [PATCH v4 1/4] refs/files: catch conflicts on case-insensitive file-systems Karthik Nayak
2025-09-17 15:25 ` [PATCH v4 2/4] refs/files: use correct error type when lock exists Karthik Nayak
2025-09-17 15:25 ` [PATCH v4 3/4] refs/files: handle F/D conflicts in case-insensitive FS Karthik Nayak
2025-09-17 15:25 ` [PATCH v4 4/4] refs/files: handle D/F conflicts during locking Karthik Nayak
2025-09-17 15:43 ` [PATCH v4 0/4] refs/files: fix issues with git-fetch on case-insensitive FS Justin Tobler
2025-09-17 18:43 ` Toon Claes
2025-09-17 19:55 ` Junio C Hamano
2025-09-17 16:20 ` 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=aLfw-peLY8NEKSZd@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=joe.drew@indexexchange.com \
--cc=karthik.188@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).