Working copy revision and push pain

Hi,

There seems to be a problem with git-push when the working copy of the directory being pushed to came from the magic revision HEAD, but not when the working copy came from some other revision.

Say I've got a repository called a:

  mkdir a
  cd a
  git-init
  echo "line 1" > file
  git-add file
  git-commit -m "commit 1" file
  echo "line 2" >> file
  git-commit -m "commit 2" file
  echo "line 3" >> file
  git-commit -m "commit 3" file

Now let's say there's a clone of repository a called b, and b has HEAD checked out. If I make changes in a and push them to b, there's a problem:

  git-clone . ../b
  echo "line 4" >> file
  git-commit -m "commit 4" file
  git-push ../b
  cd ../b
  git-log file # says the working copy came from commit 4, but...
  cat file # only lists up to line 3 :-/

If on the other hand I have a clone of repository a called c that has a non-HEAD revision checked out, there's no problem:

  git-clone ../a ../c
  cd ../c
  git-checkout HEAD^
  cd ../a
  echo "line 5" >> file
  git-commit -m "commit 5" file
  git-push ../c
  cd ../c
  git-log file # says the working copy came from commit 3, and...
  cat file # only lists up to line 3. great!

I don't know anything about the implementation of git, but could this mean that when the working copy comes from HEAD git tracks it as coming from the revision "HEAD" instead of the underlying revision's sha1? If so, this seems like an unnecessary gotcha/pain point. Couldn't git be changed to always track the sha1 of the revision it really came from? That would seem like the correct thing to do, and it would be nice to avoid unnecessarily breaking working copies.

Regards, Jonathan