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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
