git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, Joe Drew <joe.drew@indexexchange.com>,
	peff@peff.net, gitster@pobox.com
Subject: Re: [PATCH v2 1/4] refs/files: catch conflicts on case-insensitive file-systems
Date: Tue, 9 Sep 2025 09:09:54 +0200	[thread overview]
Message-ID: <aL_SwghVaAXL-yeX@pks.im> (raw)
In-Reply-To: <20250908-587-git-fetch-1-fails-fetches-on-case-insensitive-repositories-v2-1-b2eb2459befb@gmail.com>

On Mon, Sep 08, 2025 at 02:37:35PM +0200, Karthik Nayak wrote:
> diff --git a/refs.h b/refs.h
> index eedbb599c5..41915086b3 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -31,6 +31,8 @@ enum ref_transaction_error {
>  	REF_TRANSACTION_ERROR_INVALID_NEW_VALUE = -6,
>  	/* Expected ref to be symref, but is a regular ref */
>  	REF_TRANSACTION_ERROR_EXPECTED_SYMREF = -7,
> +	/* Cannot create ref due to case-insensitive filesystem */
> +	REF_TRANSACTION_ERROR_CASE_CONFLICT = -8,

Nice that we now have a specific error code for this error case. It
removes some of the guesswork we previously had to do.

> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 088b52c740..58005d2732 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -647,6 +647,19 @@ static void unlock_ref(struct ref_lock *lock)
>  	}
>  }
>  
> +static bool duplicate_reference_case_cmp(struct ref_transaction *transaction,
> +					 struct ref_update *update)

I think the name could use some improvement. How about
`transaction_has_case_conflicting_update()`?

> +{
> +	for (size_t i = 0; i < transaction->nr; i++) {
> +		if (transaction->updates[i] == update)
> +			break;

Why do we break here? Shouldn't we continue?

> @@ -776,6 +790,9 @@ static enum ref_transaction_error lock_raw_ref(struct files_ref_store *refs,
>  			goto retry;
>  		} else {
>  			unable_to_lock_message(ref_file.buf, myerr, err);
> +			if (myerr == EEXIST && ignore_case &&
> +			    duplicate_reference_case_cmp(transaction, update))
> +				ret = REF_TRANSACTION_ERROR_CASE_CONFLICT;
>  			goto error_return;
>  		}
>  	}

Okay. If we cannot lock the reference we now try to detect whether this
is because of a case conflict. That only catches the case though where
we have a case conflict in the same transaction, right? How about the
case where there's preexisting refs on disk that cause a conflict?

Patrick

  reply	other threads:[~2025-09-09  7:10 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
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 [this message]
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=aL_SwghVaAXL-yeX@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).