git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 1/4] refs/files: catch conflicts on case-insensitive file-systems

From
Karthik Nayak <karthik.188@gmail.com>
Date
Sep 17, 2025, 15:30 UTC
Message-ID
<CAOLa=ZQ7RBhqQCd4zgq4htcORWLxDsDX6t=diN+Z=TmR7H32bw@mail.gmail.com>
In-Reply-To
<CAOLa=ZR1LNs0i5TDPFG_QvUYS3=CMx3ov-68ph6QKNM273JUHQ@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
Show 46 quoted lines
>>> +
>>>  /*
>>>   * Lock refname, without following symrefs, and set *lock_p to point
>>>   * at a newly-allocated lock object. Fill in lock->old_oid, referent,
>>> @@ -677,16 +697,17 @@ static void unlock_ref(struct ref_lock *lock)
>>>   * - Generate informative error messages in the case of failure
>>>   */
>>>  static enum ref_transaction_error lock_raw_ref(struct files_ref_store *refs,
>>> -					       struct ref_update *update,
>>> +					       struct ref_transaction *transaction,
>>>  					       size_t update_idx,
>>>  					       int mustexist,
>>>  					       struct string_list *refnames_to_check,
>>> -					       const struct string_list *extras,
>>>  					       struct ref_lock **lock_p,
>>>  					       struct strbuf *referent,
>>>  					       struct strbuf *err)
>>>  {
>>>  	enum ref_transaction_error ret = REF_TRANSACTION_ERROR_GENERIC;
>>> +	struct ref_update *update = transaction->updates[update_idx];
>>> +	const struct string_list *extras = &transaction->refnames;
>>>  	const char *refname = update->refname;
>>>  	unsigned int *type = &update->type;
>>>  	struct ref_lock *lock;
>>> @@ -776,6 +797,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);
>>
>> huh, so if if we have a lockfile error due to a case-insensitve
>> filesystem, does this mean we print the error message from
>> `unable_to_lock_message()` and the new message?
>>
>> If so, I wonder if we would be better off skipping the former since it
>> could be a bit misleading.
>>
>
> I would say both are necessary. The errors added here are more technical
> and really talk about why we faced an issue. The error in
> 'builtin/fetch.c' is more about guidance to how to overcome that issue.
>
> Also this error is client agnostic, so we'd add the error here for users
> of both regular transactions and batched updates. The error in
> 'builtin/fetch.c' is very specific to users of 'git-fetch(1)'. So I
> think both hold value.
>

My response was a bit confusing here. To answer your question directly. No we do not print both messages. The error message is appended to the `strbuf err` as you see.

This 'strbuf' is provided by the callee, specifically in 'git-fetch(1)', we only print this error message if the ref transaction failed. Since 'git-fetch(1)' uses batched updates, the transaction will only fail when we encounter a GENERIC error type. Otherwise, the transaction succeeds with/without rejected updates. After which 'git-fetch(1)' will print out specific messages for rejected updates.

For example, with the test added in this patch:
  $ ~/code/git/build/bin-wrappers/git fetch -f origin
"refs/heads/*:refs/heads/*"
  remote: Enumerating objects: 3, done.
  remote: Counting objects: 100% (3/3), done.
  remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
  Unpacking objects: 100% (3/3), 713 bytes | 713.00 KiB/s, done.
  From ../base
   * [new branch]      bRanch1    -> bRanch1
   * [new branch]      branch1    -> branch1
   * [new branch]      master     -> master
   * [new branch]      bRanch1    -> origin/bRanch1
   * [new branch]      branch1    -> origin/branch1
   * [new branch]      master     -> origin/master
  error: You're on a case-insensitive filesystem, and the remote you are
  trying to fetch from has references that only differ in casing. It
  is impossible to store such references with the 'files' backend. You
  can either accept this as-is, in which case you won't be able to
  store all remote references on disk. Or you can alternatively
  migrate your repository to use the 'reftable' backend with the
  following command:
      git refs migrate --ref-format=reftable
  Please keep in mind that not all implementations of Git support this
  new format yet. So if you use tools other than Git to access this
  repository it may not be an option to migrate to reftables.
  error: fetching ref refs/remotes/origin/branch1 failed: reference
conflict due to case-insensitive filesystem
Hope that clarifies it!
Previous: Karthik NayakNext: Justin Tobler
Message 31 of 58 in “refs/files: fix issues with git-fetch on case-insensitive FS”
  1. 0/2 refs/files: fix issues with git-fetch on case-insensitive FSKarthik Nayak, Sep 2, 2025
  2. 1/2 refs/files: use correct error type when locking failsKarthik Nayak, Sep 2, 2025
  3. Chris TorekSep 2, 2025
  4. Karthik NayakSep 4, 2025
  5. Patrick SteinhardtSep 3, 2025
  6. Karthik NayakSep 3, 2025
  7. Patrick SteinhardtSep 3, 2025
  8. Junio C HamanoSep 3, 2025
  9. 2/2 refs/files: handle F/D conflicts in case-insensitive FSKarthik Nayak, Sep 2, 2025
  10. Patrick SteinhardtSep 3, 2025
  11. Karthik NayakSep 8, 2025
  12. Junio C HamanoSep 3, 2025
  13. Junio C HamanoSep 4, 2025
  14. Karthik NayakSep 8, 2025
  15. Karthik NayakSep 8, 2025
  16. 0/4 refs/files: fix issues with git-fetch on case-insensitive FSKarthik Nayak, Sep 8, 2025
  17. 1/4 refs/files: catch conflicts on case-insensitive file-systemsKarthik Nayak, Sep 8, 2025
  18. Patrick SteinhardtSep 9, 2025
  19. Karthik NayakSep 11, 2025
  20. 2/4 refs/files: use correct error type when lock existsKarthik Nayak, Sep 8, 2025
  21. Patrick SteinhardtSep 9, 2025
  22. Karthik NayakSep 11, 2025
  23. 3/4 refs/files: handle F/D conflicts in case-insensitive FSKarthik Nayak, Sep 8, 2025
  24. 4/4 refs/files: handle D/F conflicts during lockingKarthik Nayak, Sep 8, 2025
  25. Patrick SteinhardtSep 9, 2025
  26. Karthik NayakSep 12, 2025
  27. 0/4 refs/files: fix issues with git-fetch on case-insensitive FSKarthik Nayak, Sep 13, 2025
  28. 1/4 refs/files: catch conflicts on case-insensitive file-systemsKarthik Nayak, Sep 13, 2025
  29. Justin ToblerSep 16, 2025
  30. Karthik NayakSep 17, 2025
  31. Karthik NayakSep 17, 2025
  32. Justin ToblerSep 17, 2025
  33. 2/4 refs/files: use correct error type when lock existsKarthik Nayak, Sep 13, 2025
  34. Patrick SteinhardtSep 16, 2025
  35. Karthik NayakSep 17, 2025
  36. Justin ToblerSep 16, 2025
  37. Karthik NayakSep 17, 2025
  38. 3/4 refs/files: handle F/D conflicts in case-insensitive FSKarthik Nayak, Sep 13, 2025
  39. Justin ToblerSep 16, 2025
  40. Karthik NayakSep 17, 2025
  41. 4/4 refs/files: handle D/F conflicts during lockingKarthik Nayak, Sep 13, 2025
  42. Junio C HamanoSep 16, 2025
  43. Karthik NayakSep 17, 2025
  44. Toon ClaesSep 17, 2025
  45. Karthik NayakSep 17, 2025
  46. Junio C HamanoSep 17, 2025
  47. Karthik NayakSep 17, 2025
  48. Junio C HamanoSep 17, 2025
  49. Karthik NayakSep 17, 2025
  50. 0/4 refs/files: fix issues with git-fetch on case-insensitive FSKarthik Nayak, Sep 17, 2025
  51. 1/4 refs/files: catch conflicts on case-insensitive file-systemsKarthik Nayak, Sep 17, 2025
  52. 2/4 refs/files: use correct error type when lock existsKarthik Nayak, Sep 17, 2025
  53. 3/4 refs/files: handle F/D conflicts in case-insensitive FSKarthik Nayak, Sep 17, 2025
  54. 4/4 refs/files: handle D/F conflicts during lockingKarthik Nayak, Sep 17, 2025
  55. Justin ToblerSep 17, 2025
  56. Toon ClaesSep 17, 2025
  57. Junio C HamanoSep 17, 2025
  58. Junio C HamanoSep 17, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.