javabrett
commented
6 years ago https://rtyley.github.io/bfg-repo-cleaner/#usage describes and recommends running BFG on a bare-repo which is a current clone of the shared repo. I would expect that to exclude a lot of unexpected states such as in-the-middle-of-difficult-merge etc.
A repo history-rewrite is a major team-event and requires careful coordination. You should definitely finalise any complex WIP, merges etc. before a production-run, and communicate heavily with the team.
Bigpet
I know this is an unusual situation but I was using bfg on a repository that was in the middle of an octopus merge. It had some git hashes in the MERGE_HEAD.
After using bfg naturally the hashes for various branches change. If the merge is then committed afterwards its obviously wrong (or if the pruning is done before committing, the commit will just error out). It would be neat if bfg could by default just print out a warning if a merge is in progress and advise to first commit it before rewriting.
Just a small nice-to-have thing.