Remove case-insensitive dump file names handling logic

[fzhinkin]

#79 and #84 addressed the issue reported in #76 by looking up .api files in a case-insensitive manner.

To make things work smoothly on the Gradle side, we need to:

• keep track of individual files instead of a directory containing these files (which is not possible with how we supported case-insensitivity)
• keep track of directories (for check tasks, it's how we did it previously).

The latter option should work, but it requires specifying input/output directories and a file name for all the tasks. Otherwise, Gradle won't be able to track dependencies between tasks correctly. Also, all tasks consuming .api files from the repo should be updated to support case-insensitive file names (and for Klibs, the majority of tasks need it).

Note that before all the klib-related changes, the check task was using directories as its inputs, while the dump task was using files as its output, so the only way to enforce dependency between these tasks was dependsOn call.

Looking at #76 I'm not sure if macOS's case insensitivity was the root cause. The :apiDump task was based on Sync, which wipes out the destination directory before copying files. Even if the dump had a name with the wrong characters case, rerunning apiDump should have fixed it.

So, I propose removing all the logic for case-insensitive file names from the BCV and using exact file paths as Gradle task inputs/outputs.

[fzhinkin]

@ZacSweers, @joffrey-bion, @qwwdfsad PTAL. You were all involved in the original issue (#76) discussion, so I'd love to hear your thoughts on the topic.

[ZacSweers]

Definitely in favor of case-insensitivity 👍

[fzhinkin]

@ZacSweers do you have a project that relies on it?

[ZacSweers]

I don't have any projects that desire case sensitivity. The last issue was that it unexpectedly failed on CI due to CI running linux

[fzhinkin]

Looking at #76 once again. The problem is how git works on case-insensitive file systems:

• if core.ignorecase (introduced in git v1.5.6) is true (that would be the default), generated projectname.api file will be considered as just an update of ProjectName.api, on systems with case-sensitive FS, that would result in a missing dump file;
• with core.ignorecase=false, if a dump file not only changed the name, but its content was also updated, git will see a new file, but it will also update the old file, resulting in a two files in the index (and you can't check them out simultaneously on case-insensitive FS), so a git mv call would be needed.

[joffrey-bion]

Wouldn't it "just work(TM)" to make the BCV delete the old file in a case-insensitive manner, and recreate it with an exact match of the project name every time?

EDIT: ah sorry that's the case where git would just update the wrongly-cased file in the index instead of renaming it.

[fzhinkin]

BCV was always deleting the old file, the problem is how git tracks deletion and creation of a new file:

• with default git repo settings:

$ git init

$ echo "yo" > AAA.txt; git add AAA.txt; git commit -a -m 'added AAA.txt'
$ rm AAA.txt; echo YO > aaa.txt
$ git add .
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   AAA.txt

$ ls
aaa.txt

• with core.ignorecase=false

$ git init
$ echo "yo" > AAA.txt; git add AAA.txt; git commit -a -m 'added AAA.txt'
# please take care of case-insentiveness
$ git config core.ignorecase false
$ rm AAA.txt; echo YO > aaa.txt
$ git add .
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   AAA.txt
	new file:   aaa.txt

$ echo '🤡'

The only proper way to handle file name case change is git mv:

$ git mv AAA.txt aaa.txt
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	deleted:    AAA.txt
	new file:   aaa.txt

[joffrey-bion]

Yes, understood. Sorry I was too slow to update my comment apparently.

I can't believe git works this way by default. This is quite enraging. Now, is it the responsibility of BCV to deal with it? Maybe, maybe not. If we can make the experience better, why not.

So, based on what you said, even being strict from the BCV side during apiDump doesn't guarantee anything, because people could change the case of their project name between 2 generations, and git will happily save the wrong case.

I guess that leaves us no choice but to be case insensitive on the apiCheck side.

[fzhinkin]

In general, it's nice to provide a better user experience.

However, those who use core.ignorecase false continue having problems (althougt it should be easier to spot the problem).
Also, as Gradle tasks have to use directories as their inputs instead of precise file locations, and also because we store both JVM and Klibs dump in the same folder, every update of one of these dumps will invalidate all dependent tasks, which is not very nice.

[joffrey-bion]

if core.ignorecase (introduced in git v1.5.6) is true (that would be the default)

with default git repo settings

For the record, this is actually not quite correct. Git's default depends on the case-sensitivity of the local OS. So in case-sensitive systems, core.ignorecase will be false by default, which is best.

Reference: https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreignoreCase

In general, it's nice to provide a better user experience

Agreed. Although I would argue that if we get annoying Gradle behavior with task invalidation, it's worth reconsidering what experience is best.

Basically, if apiDump behaves correctly, and people are just committing wrong cases due to git's behavior on their machine, there is little BCV could do about it. The repository's state will be "incorrect" in the sense that the case of the .api file will not match the case of the project. We could indeed decide to be case-insensitive for apiCheck, but it still doesn't solve the broken state of the repo.

[joffrey-bion]

However, those who use core.ignorecase false continue having problems (althougt it should be easier to spot the problem).

Could you please expand on that? If people use core.ignorecase=false, the apiDump task will always generate correct files, and git will commit them in the correct case, right?