Understanding git filter-branch --subdirectory-filter behaviour

Hi, I'm experimenting with git filter-branch --subdirectory-filter (being specific since it appears to have several special code branches in the script) and getting results that I don't understand. Firstly, can I confirm what appears implied by the man-page but I can't find explicitly stated:

git filter-branch <how to filter> HEAD

is expected to do its filtering on the branch HEAD is on the entire DAG all the way back to the initial commit, even if this is a DAG with multiple branches splitting off and remerging?

I'm trying this on a repo (copy) containing a directory WRITING, although not quite all the way back to the repo creation getting:

$ git filter-branch --subdirectory-filter WRITING/ HEAD Rewrite 42f24be8d8198738134a19471697b39359199fa3 (351/351) Ref 'refs/heads/master' was rewritten

$ git rev-list HEAD | wc
     55      55    2255

Looking at this with gitk and git log confirms 55 commits, and the first commit is the one immediately after the first merge encountered (the commit that occured just after the merge) when walking backwards in history. Is this something that would be expected?

Digging a little into the shell-script I find the list of commits is generated with

git rev-list --reverse --topo-order --default HEAD --parents HEAD --full-history -- WRITING

and (adding --pretty so I can easily read it) running this manually gives 351 entries and looks to contain the expected commits. So I'm confused what's happening?

If this is expected, is there an refspec I'm missing to get filter-branch to filter the entire repo?

(FWIW, git version 1.5.5.1.316.g377d9 on x86-64 Linux.)

Many thanks,