git push to a non-bare repository

Hi,

I have a repository with a working tree on a machine A, did a clone to another machine B and commited there locally.

I want my changes to get back into the first repository, so I did a "push". The new commit is in the history, I can see it with "git log", but the modifications are not in the working tree.

This time, it's OK: I didn't have any uncommited modifications on A, so I just did a "git reset --hard HEAD" there.

But if I had some uncommited changes, "git reset --hard HEAD" means data loss, which is precisely what I want to avoid by using a VCS. It seems a solution is to do:

$ git reset --soft <commit-id-before-the-push> $ git merge <commit-id-after-the-push>

But it means I have to remember <commit-id-before-the-push>.

I don't understand the design choice here: git had two options to avoid this scenario:

1) update the working tree while doing the push. That's feasible with
   good performance since git is present on the server, but leaves the
   problem of possible conflicts.

2) let git remember what the local tree points to (not just the branch
   name, but the commit id itself, stored in a place that "git push"
   won't modify). Then, provide me a way to "update" to the latest
   revision.

Fyi, bzr does this. Indeed, in bzr, a branch (let's say "repository" in the git vocabulary) with a working tree just means a working tree (AKA lightweight checkout) located in the same directory as a branch. The working tree knows which revision it corresponds to, and where to find its branch. There's a "bzr update" command to get my working tree to the head of the branch, keeping the uncommited changes.

I believe this idea is very much linked to the "Lightweight Checkout" idea (listed on the SoC ideas), since, in the case of multiple working directories sharing the same .git, you don't want a commit in one tree to affect the others.

So, did I miss something? Is there anything on the todo-list?

Thanks,