Hi Junio, first of all, my apologies for the incorrect commit message (you missed it, too, though): it is not about respecting core.fileMode, but about core.ignoreCase. On Tue, 25 Dec 2018, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > the resulting index entry is "blub" or "BLUB". Shouldn't we verify > > that "git add" adds an expected path to the index, instead of > > blindly trusting that it says "Yeah, I did as I was told" with its > > exit status? Would we be adding 'blub' as that is what we told > > 'git' to add, or would it be 'BLUB' as that is what exists on the > > filesystem that is case insensitive but case preserving? > > Needless to say, the last part of the above is a mere thetorical > question, and I am not questioning the established behaviour or > suggesting to "improve" it. On a case insensitive filesystem, we > trust what readdir() gave us (but match them with pathspec case > insensitively) for a new path that is not in the index. When we > update the contents of a path that is already in the index, we > preserve the case in the index, even when readdir() reports the same > path in different case (iow, we trust the case in the index more > than what readdir() gives us).. > > What I am wondering in the above is if we should document that in > the test, perhaps with a simple > > git ls-files blub >actual && > echo BLUB >expect && > test_cmp expect actual > > or something like that. Actually, I would interpret the description in our documentation to mean that Git does not want to trust what readdir() gave us but heed what the user said, i.e. when `BLUB` is added as `git add blub`, Git really should think that it is `blub`, not `BLUB` (i.e. the exact opposite of what you suggest). From Documentation/config/core.txt's section about `core.ignoreCase`: For example, if a directory listing finds "makefile" when Git expects "Makefile", Git will assume it is really the same file, and continue to remember it as "Makefile". Ciao, Dscho
