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

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.


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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to