I think that the approach has one huge advantage.  Commands
other than "git commit" itself ("git merge", "git rebase", "git
am", etc.) do call "git commit" to record the changes they made.
I suspect these command would not want this template behaviour,
and not adding this custom commit message "feature" to "git
commit" would avoid the risk of breaking them.

My patch does not do that.  Of all these commands, only git-rebase uses 
porcelain git-commit rather than plumbing git-commit-tree, and it uses 
the -C or -F options (which disable the hook in my patch).

At the same time, this exact issue could be a drawback.  Some of
them _might_ want it.  But in that case, the the custom template
"hook" needs to be told _why_ it is being called, so that it can
adjust its behaviour.

I would like to understand why both of you have not considered the point 
  that the script would need the updated index from git-commit.  Because 
short of reusing half of the old Bourne-shell git-commit, I don't see 
how this would be possible, but maybe there's something obvious.  Or 
maybe we need new plumbing like git-build-index -- then I'd still need 
to complicate my script to build a template commit message, but I 
wouldn't need to muddle myself (not too much at least) in handling the 
command line.

Paolo