search

rtyley / bfg-repo-cleaner

Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala
https://rtyley.github.io/bfg-repo-cleaner/
GNU General Public License v3.0
11.11k stars 549 forks source link

Is there a way to suppress the REMOVED.git-id placeholders? #293

Closed kelseymh closed 6 years ago

kelseymh commented 6 years ago

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 a git clone produces a work area with the REMOVED.git-id files in place. Is there something else I will need to do instead?

kelseymh commented 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.

javabrett commented 6 years ago

I have a PR for this, #140. This issue probably duplicates #139.

kelseymh commented 6 years ago

You're right, it does effectively duplicate #139 . In that case, I will close this.