Torsten Bögershausen [off-list ref] writes:

On Tue, Dec 29, 2020 at 02:06:37AM +0000, Dan Moseley wrote:

First of all, thanks for submitting this to git.git.
I take the freedom to add some comments here.

quoted

Fix git mv to not assert when src is already in the index under a
different casing, core.caseInsensitive=true, and the file system
is case insensitive.

The config variable is named core.ignorecase

Does it make sense to illustrate the use case here, like this:

 git init
 echo foo >foo
 git add foo
 git mv foo FOO
 git mv foo bar

quoted

Since 9b906af657 the check that git mv does to ensure the src is in the
cache respects caseInsensitive. As a result git mv allows a move from a
file that has a different case in the index than it does on disk.
After the rename on disk, git mv fails to find the file in the cache
in order to rename it in the index, and asserts.
Assertion failed: pos >= 0, file builtin/mv.c, line 295

This is the simplest possible fix, suggested by @tboegi. It does leave
the file renamed on disk, but that is easy to reverse after the error.

We can expand the short-ish "@tboegi" into a "Helped-by" line, please see below.
And refrase the paragraf like this:

This is the simplest possible fix, it avoids to leaving a .git/index.lock
behind.  It does leave the file renamed on disk,
but that is easy to reverse after the error.

Sorry but I feel lost here.  So this is not a fix with which the end
user does not have to do anything after kicking in?  The only thing
it "fixes" is to avoid hitting a BUG() or something that can leave
the .lock file behind (so that the user does not have to run "rm
.git/index.lock" after the operation)?