bfg-repo-cleaner
bfg-repo-cleaner copied to clipboard
rtyley
all branches that were named feature/ got renamed Feature/
I used the BFG tool to redact sensitive data (using the --replace-text option), and when I ran the tool it took every existing branch that started with the characters "feature/" (a common naming pattern in the repo) and duplicated the branch, leaving the existing branch "feature/" (unclear to me if these are clean or dirty) and creating a new clean (verified they were clean) branch "Feature/". I am on a mac and using a bash terminal.
There were other branches with slashes, which as "bugfix/" that did not get duplicated or capitalized.
Does anyone have any information about why this occured?
Thank you.
@rtyley Curious if you have seen this issue before or have a sense of why it occurred. Thanks for your time.
Do you perhaps have a branch originally named Feature/XYZ? I think if BFG iterates through capitalized branches first, it creates a Feature folder in git, and then prefers those folders over a feature folder for other branches.
I'm experiencing the same issue BTW.
Related stack overflow link https://stackoverflow.com/questions/52265685/git-filter-branch-and-bfg-repo-cleaner-creating-duplicate-branches
Happening to me as well, guess the solution is to rename ALL branches to be lowercase before running BFG.
I had the same problem today.
We've got a commit from 8 years ago in one of our repos that improperly removed a submodule and created a corrupt commit, so we're running a --fix-filename-duplicates-preferring tree to repair it and rewrite all the history since. After running it however we've found that a number of our branches have duplicated. Things like bugfix/some-branch-name haven't been touched and instead the replacement commits have been pushed to Bugfix/some-branch-name. Since the old bugfix/some-branch-name still exists and still has the corrupt commit, the git gc isn't deleting it and we're still blocked from migrating the repo to Azure DevOps.
After looking around on StackOverflow, I found an issue that references your operating system being part of the problem. It suggests running whatever your doing on a case-sensitive file system instead, so I gave it a shot on an Amazon Linux box. Everything works fine when ran from there, the branches haven't duplicated and the bad commit is easily GC'd.
If anybody is coming here in the future looking for help, give that a shot. Sounds like it's just some annoying nonsense from Git itself, as I've had similar case-sensitivity problems from other tools.
