Closed kelseymh closed 6 years ago
I did find a workaround, but I'm curious whether it's revealing an underlying bug (or different assumptions?) compared to what I understood from the documentation. If I do the following two actions
bfg --private -b 5M --no-blob-protection myMirror.git
bfg --private -D '*REMOVED.git-id' --no-blob-protection myMirror.git
then I end up with the repository in the state I want. Of course, this means there were two passes, and two changes of commit SHA. If this is the expected behaviour, feel free to just close the issue.
I have a PR for this, #140. This issue probably duplicates #139.
You're right, it does effectively duplicate #139 . In that case, I will close this.
I am preparing to apply BFG (the latest distribution, downloaded 26 Sep 2018) to my "real" project repository, to get rid of a bunch of excessively large files I put into it six months ago. It appears to work beautifully (and many thanks for providing it!), but I'd like to do one additional thing to keep my end users/developers from getting confused.
Is there a way (as part of the BFG run itself) to not create these files? I have read through the documentation and related issues, and I understand their utility. In my testing (i.e., without pushing back to the real repository), they provide exactly the information they're supposed to. But I think they will confuse my end users, and so I'd like to eliminate them when I run this for real.
I tried using the
--private
option (bfg -b 5M --no-blob-protection --private
), but even after that, doing agit clone
produces a work area with the REMOVED.git-id files in place. Is there something else I will need to do instead?