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. Generally, this pattern seems to be a correct way to do this:
1. git filter-branch --index-filter 'git rm --cached --ignore-unmatch core.4563' HEAD 2. edit .git/packed-refs to remove the line "[hash] refs/original/refs/heads/master" (so that there is no reference to the old HEAD) 3. git gc --quiet --aggressive (to remove the space used by the big file, which is no longer referenced) 4. git reset -q HEAD (to ensure that the index matches HEAD) 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, so the filtering would not affect the working copy at all.) A further difficulty is that the repository is "remote", the .git directory is not in my home directory, and core.worktree is "/home/worley". If the current directory is the parent of .git, "git filter-branch" complains "You need to run this command from the toplevel of the working tree." This is peculiar, because other Git commands (e.g., "git commit" and "git add") work correctly when the current directory is the parent of the .git of a remote repository. (After all, core.worktree tells where the working copy is.) 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. It appears to me that two validity checks should be relaxed: (1) "git filter-branch" should work when run from the parent of .git of a remote repository. (2) "git filter-branch --index-filter" should check that the index is "clean", but not the working copy files. Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
