On Thu, Aug 21, 2025 at 09:15:47AM +0200, Patrick Steinhardt wrote: > > > This error _does not_ happen in the Apple-supplied version of git: > > > `git version 2.39.5 (Apple Git-154)`, but does in 2.51.0, which I > > > installed with homebrew. (If this is a packaging error, I'll happily > > > report to homebrew.) > > > > That is definitely weird, and not something I'd expect if it's just a > > case collision. Is it possible for you to build Git from source? If so, > > and the problem happens with your build of 2.51.0 but not v2.39.5, it > > would be very enlightening to see the results of "git bisect". We can > > provide more guidance if you need with that process. > > Curious indeed. Another relevant part could be the new batched mode that > we have recently introduced in git-fetch(1). Previously we would've > updated refs one by one, and potentially that led to us writing the same > ref multiple times due to case-insensitivity? The result would be quite > broken in that case, but at least the fetch would've finished. Does make > me wonder though what subsequent fetches did, and whether we always tend > to flip-flop the value of such a ref. Ah, good catch. That would explain the behavior change perfectly. My money is on a case collision, then. :) > But with batched transactions that's not possible anymore, as we would > indeed try to lock the same ref twice. Assuming that this really is the > case, I wonder whether we should detect this case, tell the user that > it's impossible to store all refs on their system, and then continue > regardless while ejecting that specific ref from the transaction. Maybe it is too optimistic to think that they will just start using reftable in Git 3.0, and we can avoid extra code to detect this? -Peff
