Tao Klerks <tao@xxxxxxxxxx> writes: >> We need a new test or two to see if a straight creation or deletion >> patch does work correctly with icase set, before we even dream of >> handling rename patches. Not having tests for such basic cases is >> quite surprising, but apparently the above line passed the CI. > > This is where I made some very bad assumptions: I only manually ran > the new "t4141-apply-case-insensitive-rename.sh" test, and assumed > that the test suite ran against linux, windows, and OSX, with the > latter two running on case-insensitive filesystems. I assumed that > both case-sensitive and case-insensitive code paths would be tested by > the complete CI suite. Apparently we were surprised the same way ;-) > *Do* we expect to run the full test suite on case-insensitive systems > in gitlab, or do we expect to need to add explicit "-C > core.ignorecase" tests as you have done here? Running all tests on case-insensitive systems and expect them to pass is reasonable; we need to sprinkle !CASE_INSENSITIVE_FS prerequiste to skip certain tests that exercise functionalities that case insensitive filesystem will never be able to support (e.g. you cannot by their design have file1.txt and File1.txt at the same time on the filesystem, so any test with "test_cmp file1.txt FIle1.txt" must be marked with !CASE_INSENSITIVE_FS prerequisite). When the system I am primary owrking on is case sensitive, it is always nice to be able to discover that I broke something on case INsensitive system before I conclude my WIP into a commit and throw it at CI. We may have to case-insensitively treat the paths in the index in order to match what the working tree would do to make "git checkout -- <path>" work case-insentively, and doing in-index-only mode of operation with core.ignorecase=yes on case-sensitive system may be a way to "emulate" some of the requirement case-insentive systems have with these "-c core.ignorecase" trick, but of course not all scenarios can be tested without being on case-insensitive systems. So we need both, I think.
