The branch filter works only after starting twice
To remove build results from our repository, I ran git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch */obj/*' -- --all
. It seems to have worked.
Oddly enough, the launch git log --oneline --name-only --all -- */obj/*
displays a list of commits that still contain the directory obj
.
So, I ran a filter-branch
second time. Git told me:
Rewrite d57c56e00f713854d8b5889a259e10bd9be6a83c (316/316)
WARNING: Ref 'refs/heads/master' is unchanged
WARNING: Ref 'refs/remotes/origin/master' is unchanged
WARNING: Ref 'refs/remotes/origin/carousel' is unchanged
WARNING: Ref 'refs/remotes/origin/master' is unchanged
Now when I run the command again the log
history is empty. The catalog is obj
no longer in history. That's fine, of course, but the question remains: Why would I run twice filter-branch
?
source to share
Presumably those that appear after the first filter-branch
were named after refs/original/refs/heads/master
and the like. --all
means all links under refs/
. Remember, it filter-branch
saves (kind of restores) the original references to refs/original/
(or whatever namespace you define with --original
). You can use them to get things back in case the filter branching operation made a mess.
C -f
(force) filter-branch
will be run even if there is already a namespace for the backup branches: it deletes the old backup to make room for the new one. Without -f
it, it does the following:
die "Cannot create a new backup.
A previous backup already exists in $orig_namespace
Force overwriting the backup with -f"
By deleting the backup, the second operation filter-branch
deleted all the entries refs/original/
- something that you usually have to do manually once you are happy with the filter's result. In this case, since reapplying the filter harmlessly did nothing, the second filter-branch
took care of cleaning you up.
source to share