Am I supposed to run BFG on the mirrored repo or the original?

I want to delete two files from my git repo that aren’t there anymore.

I put them in, committed, and tried to push but they were too large. So I took them out, and kept working, then committed, tried to push, but it still gave me the same error. I figured they’re still in the history somewhere.

  • Git Merge Duplication after Ineffective BFG Use
  • I have used bfg cleaner for removing large blob files
  • BFG which repo to use after successful run
  • How to delete one folder / directory using BFG repo cleaner?
  • How to update/shrink the size of my github repo after running BFG Repo Cleaner
  • How to find the git object id of an object with a known hash
  • I think I made the problem worse because I kept working in that branch and made 1 more commit. Then I merged that branch back to the master branch.

    So I searched for a solution and found bfg.

    But the instructions on the page don’t make sense to me.

    First off,

    $ git clone --mirror git://

    Where am I supposed to clone from? My remote repo on doesn’t have the commits and the merge I did since I added the large files. But the instructions make it seem like I’m supposed to get it from there anyway. (I cloned from my local repo.)


    $ java -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.git

    Is some-big-repo.git the mirrored repo or the normal local repo?
    (I used the mirrored repo for this.)

    And then I checked that my history had been updated and tried,

    $ cd some-big-repo.git
    $ git reflog expire --expire=now --all && git gc --prune=now --aggressive

    (I was in the mirrored clone for this) I got an error.

    remote: error: refusing to update checked out branch: refs/heads/master
    remote: error: By default, updating the current branch in a non-bare repository
    remote: error: is denied, because it will make the index and work tree inconsistent
    remote: error: with what you pushed, and will require 'git reset --hard' to match
    remote: error: the work tree to HEAD.
    remote: error: 
    remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
    remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
    remote: error: its current branch; however, this is not recommended unless you
    remote: error: arranged to update its work tree to match what you pushed in some
    remote: error: other way.
    remote: error: 
    remote: error: To squelch this message and still keep the default behaviour, set
    remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
    To /home/cole/main_repo
     + 94b9a0d...c7c4317 work -> work (forced update)
     ! [remote rejected] master -> master (branch is currently checked out)
    error: failed to push some refs to '/home/cole/main_repo'

    This makes sense to me. Yeah I do currently have master checked out. But then, what else was I supposed to do? I can only see problems happening if I try it another way.

  • git bash auto complete slow on windows 7 x64
  • GIT: is a tag unique per commit?
  • Git merge conflicts when no changes done
  • How do I keep an svn:external up to date using git-svn?
  • How to automatically resolve a Git conflict by taking the version in the current branch?
  • How do I view older iterations of binary (image or non-code) files from a git repository?
  • One Solution collect form web for “Am I supposed to run BFG on the mirrored repo or the original?”

    You should clone/mirror the repo that you eventually plan to replace the commits-in, but there’s an underlying assumption that this repo is also a bare repo. This would usually be a remote repo, but you might also clone a local repo to save bandwidth.

    The underlying assumption is that the repo where you will eventually store your cleaned repository is also a bare repo. Server-based repos e.g. GitHub are usually exactly that.

    In your case it sounds like you have cloned a local, non-bare (contains a HEAD and working-copy) repo, either to save bandwidth, or because it is the repo that contains the commits you wish to clean. Either way, in order to push back into a non-bare repo, you need to make sure you don’t have any refs you want to push checked-out, including master.

    From your comment it looks like you found the solution, which is to push-back to the eventual origin repo, which will likely be a bare repo.

    Git Baby is a git and github fan, let's start git clone.