aboutsummaryrefslogtreecommitdiffstats
path: root/refs.c
diff options
context:
space:
mode:
authorKarthik Nayak <karthik.188@gmail.com>2025-09-17 17:25:14 +0200
committerJunio C Hamano <gitster@pobox.com>2025-09-17 09:19:08 -0700
commit948b2ab0d88770368a7fed5a651c17db1c7f9b28 (patch)
treee8113f0a49eb818b7da8b0d03df55ae3a63c1238 /refs.c
parentrefs/files: handle F/D conflicts in case-insensitive FS (diff)
downloadgit-948b2ab0d88770368a7fed5a651c17db1c7f9b28.tar.gz
git-948b2ab0d88770368a7fed5a651c17db1c7f9b28.zip
refs/files: handle D/F conflicts during locking
The previous commit added the necessary validation and checks for F/D conflicts in the files backend when working on case insensitive systems. There is still a possibility for D/F conflicts. This is a different from the F/D since for F/D conflicts, there would not be a conflict during the lock creation phase: refs/heads/foo.lock refs/heads/foo/bar.lock However there would be a conflict when the locks are committed, since we cannot have 'refs/heads/foo/bar' and 'refs/heads/foo'. These kinds of conflicts are checked and resolved in `refs_verify_refnames_available()`, so the previous commit ensured that for case-insensitive filesystems, we would lowercase the inputs to that function. For D/F conflicts, there is a conflict during the lock creation phase itself: refs/heads/foo/bar.lock refs/heads/foo.lock As in `lock_raw_ref()` after creating the lock, we also check for D/F conflicts. This can occur in case-insensitive filesystems when trying to fetch case-conflicted references like: refs/heads/Foo/new refs/heads/foo D/F conflicts can also occur in case-sensitive filesystems, when the repository already contains a directory with a lock file 'refs/heads/foo/bar.lock' and trying to fetch 'refs/heads/foo'. This doesn't concern directories containing garbage files as those are handled on a higher level. To fix this, simply categorize the error as a name conflict. Also remove this reference from the list of valid refnames for availability checks. By categorizing the error and removing it from the list of valid references, batched updates now knows to reject such reference updates and apply the other reference updates. Fix a small typo in `ref_transaction_maybe_set_rejected()` while here. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'refs.c')
-rw-r--r--refs.c9
1 files changed, 8 insertions, 1 deletions
diff --git a/refs.c b/refs.c
index 4c1c339ed9..e7109ea5fe 100644
--- a/refs.c
+++ b/refs.c
@@ -1223,7 +1223,7 @@ int ref_transaction_maybe_set_rejected(struct ref_transaction *transaction,
return 0;
if (!transaction->rejections)
- BUG("transaction not inititalized with failure support");
+ BUG("transaction not initialized with failure support");
/*
* Don't accept generic errors, since these errors are not user
@@ -1232,6 +1232,13 @@ int ref_transaction_maybe_set_rejected(struct ref_transaction *transaction,
if (err == REF_TRANSACTION_ERROR_GENERIC)
return 0;
+ /*
+ * Rejected refnames shouldn't be considered in the availability
+ * checks, so remove them from the list.
+ */
+ string_list_remove(&transaction->refnames,
+ transaction->updates[update_idx]->refname, 0);
+
transaction->updates[update_idx]->rejection_err = err;
ALLOC_GROW(transaction->rejections->update_indices,
transaction->rejections->nr + 1,