Unexpected results on repo with filename case changes about git-filter-repo HOT 7 CLOSED

Okay, I added '-c core.ignorecase=false' to the command line for the git fast-import invocation, which should prevent anyone else from running into this issue (well, assuming they're using a the version from master or some future release of filter-repo).

Thanks for the detailed report, @m4tiz5zktonj !

from git-filter-repo.

Yeah, that's what I expected. When you clone a repository, git attempts to check if the filesystem is case-insensitive and sets that config value at clone time for the local repo accordingly.

It looks like git in config.c sets ignore_case based on the setting of core.ignoreCase, and then fast-import.c uses fspathncmp() to compare entries, which when ignore_case is true translates to strncasecmp(). That means fast-import is treating two files within a single commit as the same file. fast-export will emit both a delete-old-file and create-new-file-with-same-contents directive (likely in alphabetical order of the filenames) whenever it sees a rename, but fast-import is basically ignoring whichever of those directives came first since it treats them as the same file and considers the second as an override.

Can you try unsetting the local setting of core.ignoreCase (git config --unset core.ignoreCase), then running filter-repo, then setting core.ignoreCase again (git config core.ignoreCase true)?

from git-filter-repo.

What's the output of git config core.ignorecase? I wonder if I need to override that and set it to false...

from git-filter-repo.

$ git config --local core.ignoreCase
true

$ git config --global core.ignoreCase
<empty output>

I haven't changed it so it falls back to default values for git installation and for .git folder template for new repositories.

from git-filter-repo.

Yes, you're right.
With unset core.ignoreCase everything works fine on test repo: tree is the same and git log is correct.
On my real giant repo everything seem OK too, at least tree as I expected has not changed and history of several problematic files looks normal.
Thank you very much!

from git-filter-repo.

Would be great to add this to the manual or readme. Or even embed to the script.

I am using git-filter-repo as part of migration of two android repositories to the monorepo. Had an issues with project building on CI server (hosted on Linux) while it was running fine on my local machine (Mac OS). Had to spend almost two days to figure out that somewhere in the middle directory name was upper case while it is lowercase in the original repo.

from git-filter-repo.

Would be great to add this to the manual or readme. Or even embed to the script.

I am using git-filter-repo as part of migration of two android repositories to the monorepo. Had an issues with project building on CI server (hosted on Linux) while it was running fine on my local machine (Mac OS). Had to spend almost two days to figure out that somewhere in the middle directory name was upper case while it is lowercase in the original repo.

Sorry that insane broken-by-design filesystems caused you so much pain, it's a pity we can't just get rid of those and instead have to waste so many engineering cycles working around them. But, since they won't be going away, it does make sense to try to work around them where practical. Anyway, embedding the workaround in git-filter-repo is precisely the plan; this issue was left open as a reminder to do that.

from git-filter-repo.