Unhelpful git-rebase error when untracked files conflict with new head

Just helped someone figure out what was going on with a rebase  
failure. The error message from git-rebase is pretty confusing and  
unhelpful when there's a conflicting untracked file in the working  
copy. Example:

[ create a repo with 1 commit and 1 file ]
$ mkdir parent
$ cd parent
$ git init
Initialized empty Git repository in .git/
$ touch foo
$ git add foo
$ git commit -m 'initial commit'
Created initial commit 97aef94: initial commit
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 foo
$ cd ..

[ clone it and create a second file in both parent and child,  
committing it in parent ]
$ git clone parent child
Initialized empty Git repository in /home/koreth/test/child/.git/
$ touch parent/bar child/bar
$ cd parent
$ git add bar
$ git commit -m 'second commit'
Created commit 40d4be0: second commit
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 bar

[ try to rebase to the parent's second commit in the child ]
$ cd ../child
$ git fetch
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
 From /home/koreth/test/parent/
    97aef94..40d4be0  master     -> origin/master
$ git rebase origin/master
First, rewinding head to replay your work on top of it...
could not detach HEAD

"could not detach HEAD" tells you basically nothing about what's going  
on. I spent a fair while scratching my head over this, because I was  
perfectly able to detach HEAD by hand (checking out old revisions,  
etc.) It would be more accurate to say, "Could not check out the  
revision you're rebasing onto."

If you run git-rebase under strace, there actually *is* a meaningful,  
helpful error message being generated by "git checkout":

...
[pid 11353] write(2, "error: Untracked working tree file \'bar\' would  
be overwritten by merge.\n", 72) = 72
...

but it gets discarded rather than shown to the user.

Are we suppressing output from git-checkout intentionally? Are there  
specific error messages other than this one that we don't want to show?

-Steve