On 12/11/2019 1:44 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> Another option would be to do case-insensitive checks while >> updating the skip-worktree bits during unpack_trees(). Outside of >> the potential performance loss on a more expensive code path, that >> also breaks compatibility with older versions of Git as using the >> same sparse-checkout file would change the paths that are included. > > I haven't thought things through, but that sounds as if saying that > we cannot fix old bugs. We use the entries in the index as a hint > for "correcting" a path to the right case on a case-insensitive > filesystem to avoid corrupting the case in the index, which is case > sensitive and is a way to convey the intended case (by writing them > out to a tree object) to those who use systems that can reliably > reproduce cases in pathnames. But that still does not mean on a > case-insensitive filesystem, "hello.c" in the "right" case recorded > in the index will always be spelled like so---somebody can make > readdir() or equivalent to yield "Hello.c" for it, and if the user > tells us to say they want to do X (e.g. ignore, skip checkout, etc.) > to "hello.c", we should do the same to "Hello.c" on such a system, I > would think. > > If the runtime needs to deal with the case insensitive filesystems > anyway (and I suspect it does), there isn't much point matching and > forcing the case to the paths in the index like this patch does, I > think. So... I'm trying to find a way around these two ideas: 1. The index is case-sensitive, and the sparse-checkout patterns are case-sensitive. 2. If a filesystem is case-insensitive, most index-change operations already succeed with incorrect case, especially with core.ignoreCase enabled. The approach I have is to allow a user to provide a case that does not match the index, and then we store the pattern in the sparse-checkout that matches the case in the index. Another approach would be to make the sparse-checkout patterns be case-insensitive when core.ignoreCase is enabled. I chose against this due to the compatibility and the performance cost. We would likely pay that performance penalty even if all the patterns have the correct case. It violates the existing "contract" with the sparse-checkout file, and that is probably what you are talking about with "we cannot fix old bugs". It sounds like you are preferring this second option, despite the performance costs. It is possible to use a case-insensitive hashing algorithm when in the cone mode, but I'm not sure about how to do a similar concept for the normal mode. Thanks, -Stolee
