The deed is done.
pike.git has been filtered, and is now open for pushing again.
Of course, you'll need to rebase your work first. As I said before, a simple "git pull" should take care of that if you have a branch that tracks a pike.git branch by rebasing. (Do not use "git rebase @{upstream}", it doesn't use the reflog so it won't work.) For more advanced branch structures, some manual work might be involved. If your branch was previously based on unfiltered commit X, you can find the filtered version Y of that commit by consulting the following file (each line contains old SHA and new SHA, or old SHA and "-" if the commit was deleted):
http://pike-svn.lysator.liu.se/twiki/pub/Main/RepoFilter/sha_map
Then run "git rebase --onto Y X" and all should be fine.
Once all your branches are rebased, I recommend a "git gc" to get rid of all those unfiltered commits.
For future reference, the following file
http://pike-svn.lysator.liu.se/twiki/pub/Main/RepoFilter/rebased_commits
details the commits which were changed from merges to cherry-picks. There are four SHA:s per line, namely
* Old SHA of merge * New SHA of cherry-pick * Old SHA of commit which was merged * New SHA of commit which was cherry-picked
So finding cherry-picks of the same commit only amounts to grouping on column 3 or 4.