Using filter-branch without messing up the working copy

Using filter-branch without messing up the working copy

[Dale R. Worley]

I'm working on using "git filter-branch" to remove the history of a
large file from my repository so as to reduce the size of the
repository.  This pattern of use is effective for me:

1. $ git filter-branch --index-filter 'git rm --cached --ignore-unmatch core.4563' HEAD

2. edit .git/packed-refs to remove the line
   "c6589bef2c776277407686a3a81c5a76bfe41ba2 refs/original/refs/heads/hobgoblin"
(so that there is no reference to the old HEAD)

3. git gc --quiet --aggressive

The difficulty I am having is that I do not want to disturb the
working copy while doing this.  The working copy is my entire home
directory, because I am using the repository as a historical backup
system for my home directory.  Currently, Git will not execute
filter-branch if there are unstaged changes in the working copy,
despite the fact that "git filter-branch --index-filter" does not
touch the working copy itself.  (In this case, the file to be deleted,
"core.4563", is not now in the working copy.)

A further difficulty is that the repository is "remote", the .git
directory is not in my home directory, and core.worktree is
"/home/worley".

The best set of steps I have found that accomplishes my goals is to
(1) "disconnect" the repository from the working copy by removing the
core.worktree value, (2) use "git checkout -q -f master" to create in
the repository's location an entire copy of my home directory, (3)
perform the above filtering steps, (4) "reconnect" the repository by
adding the core.worktree value, and (5) deleting the temporary working
copy files.

Surely there is a better way than this.

Dale