TL;DR: Please implement a sanity check as described under Proposed solution.
Context
I'm working on a large private repository inside my company. I can't share the repository, but I can give you enough information to hopefully make this bug reproducible and avoidable.
This repository has hundreds of (old) branches. Including these:
And I'm using a MacBook provided by my employer. And the default filesystem in Mac OS is case insensitive. I believe the same bug could happen on Windows.
What I tried to do
I was trying to remove old obsolete binary files from the repository. I tried:
git filter-repo --invert-paths --path-glob '*.zip' --path-glob '*.jar'
And I was puzzled why it would often not work at all (the binaries would stay there in the git history) without any error message whatsoever.
Sometimes, after a few tries, I would get a cryptic error:
Traceback (most recent call last):
File "/Users/foobar/.homebrew/bin/git-filter-repo", line 4976, in <module>
main()
~~~~^^
File "/Users/foobar/.homebrew/bin/git-filter-repo", line 4973, in main
filter.run()
~~~~~~~~~~^^
File "/Users/foobar/.homebrew/bin/git-filter-repo", line 4936, in run
self._record_metadata(self.results_tmp_dir(), self._orig_refs)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/foobar/.homebrew/bin/git-filter-repo", line 4767, in _record_metadata
self._compute_metadata(metadata_dir, orig_refs)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/foobar/.homebrew/bin/git-filter-repo", line 4712, in _compute_metadata
assert(usoa == intermediate) # old wasn't pruned => usoa == intermediate
^^^^^^^^^^^^^^^^^^^^
AssertionError
When it happened, I assumed the repository was borked and I restarted from scratch.
After many hours, I randomly got this error message:
Aborting: Cannot rewrite history on a case insensitive
filesystem since you have refs that differ in case only:
refs/heads/POC/bar, refs/heads/poc/bar
Note how one of those branch names is already incorrect (the case has changed). This was likely due to the local clone of this repository being FUBAR. Of course, after such error I just deleted it and restarted from scratch, again.
What is the problem?
git-filter-repo assumes the filesystem will be case-sensitive, or that no branch names (or subdirectories) will clash. Then it just continues doing the work as usual… until things break or misbehave.
Proposed solution
Please implement some sanity check to detect this combination of factors:
- If the file system is case insensitive, and…
- The branches|tags|refs differ only in case, or…
- The branches|tags|refs share a common (sub)directory prefix that differs only in case…
Then this combination of factors is a recipe for disaster, and the tool should abort early, without making any modifications, with a clear error message.
I understand this combination of factors is rare, and no one thought about checking it beforehand. That's why I'm reporting this bug, and asking to implement such sanity check. It would have saved me so many hours… ;)
Workaround, or solution for my private repository
In my case, I was able to delete those offending branches, and then the tool seemed to work just fine. The difficulty was knowing the branch names were a problem, and knowing which branch names were clashing.
TL;DR: Please implement a sanity check as described under Proposed solution.
Context
I'm working on a large private repository inside my company. I can't share the repository, but I can give you enough information to hopefully make this bug reproducible and avoidable.
This repository has hundreds of (old) branches. Including these:
poc/fooPOC/barAnd I'm using a MacBook provided by my employer. And the default filesystem in Mac OS is case insensitive. I believe the same bug could happen on Windows.
What I tried to do
I was trying to remove old obsolete binary files from the repository. I tried:
And I was puzzled why it would often not work at all (the binaries would stay there in the git history) without any error message whatsoever.
Sometimes, after a few tries, I would get a cryptic error:
When it happened, I assumed the repository was borked and I restarted from scratch.
After many hours, I randomly got this error message:
Note how one of those branch names is already incorrect (the case has changed). This was likely due to the local clone of this repository being FUBAR. Of course, after such error I just deleted it and restarted from scratch, again.
What is the problem?
git-filter-repoassumes the filesystem will be case-sensitive, or that no branch names (or subdirectories) will clash. Then it just continues doing the work as usual… until things break or misbehave.Proposed solution
Please implement some sanity check to detect this combination of factors:
Then this combination of factors is a recipe for disaster, and the tool should abort early, without making any modifications, with a clear error message.
I understand this combination of factors is rare, and no one thought about checking it beforehand. That's why I'm reporting this bug, and asking to implement such sanity check. It would have saved me so many hours… ;)
Workaround, or solution for my private repository
In my case, I was able to delete those offending branches, and then the tool seemed to work just fine. The difficulty was knowing the branch names were a problem, and knowing which branch names were clashing.