checkout/update boiler plate for --filter-index?

I'm trying to do a historical find-and-replace on my code:

git grep -F foo > files
git filter-branch --index-filter "
   cat `pwd`/files | xargs git checkout  --
   cat `pwd`/files | xargs sed -i 's/foo/bar/g; '
   cat `pwd`/files | xargs git update-index --
" ancestor..HEAD

When I instead use --tree-filter and skip the checkout/update-index, it works how I want (but it takes a while...). But when I use --index- filter, the resulting history shows the "foo" to "bar" change happening *after* new code is added, rather than originally adding "bar".

How can I checkout just a few files and update them to take advantage of the speed of index operations?

Marcel

Marcel Cary schrieb:

You cannot do that with the index filter because you need actual blob contents to operate on, but the index filter doesn't give you an opportunity to do that. The tree filter is the right filter to use. But you neither need 'git checkout' nor 'git update-index' in the filter - filter-branch calls them for you. (Oh, and get rid of that useless use of cat.)

-- Hannes

On Tue, Mar 24, 2009 at 08:21:06AM +0100, Johannes Sixt wrote:

Well, you _could_ do it as an index-filter, which has the potential to be much faster if you are only operating only on a small subset of the files. But it's much less readable. Something like (totally untested):

  git filter-branch --index-filter '
    for i in `cat /path/to/files`; do
      hash=$(git cat-file :$i |
             sed 's/foo/bar/' |
             git hash-object -w --stdin)
      git update-index --add --cacheinfo 100644 $hash $i
    done
  '

I'm sure you could do even do it with a constant number of processes per commit by using update-index --index-info, hash-object --stdin-paths, and cat-file --batch. But it would probably be even less readable. ;)

Personally, I would probably just do a tree-filter for simplicity unless the repo size made it prohibitively slow.

-Peff