Working copy revision and push pain

[Jonathan Watt <jwatt@jwatt.org>]

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