Re: disallowing push to currently checked-out branch

as I think about this more I'm puzzled as to why this is an issue.

I see mentions of it messing up the index and causing users to loose data, 
but how is it different to push into a repository that has a workdir (with 
or without dirty state in the workdir or in the index) and doing a fetch 
into that repository.

in both cases the new commits are added to the repository and the commit 
pointed to by the branch changes, but if you do the fetch your HEAD and 
the contents of the workdir and index aren't touched, why should a push do 
something different?

I believe that if you fetch into a repository and someone else fetches 
from you, they will get the content that's newer that what's in your dirty 
workdir/index (I haven't tried it, but my understanding of the git 
internals lead me to expect this to be the behavior)

a pull would try to update the index, HEAD, and workdir, but I've seen 
many discussions about how push and pull are not symetrical, but push and 
fetch are (along with the moaning about bad names for the commands and the 
historical explination of how they got that way)


If there is some reason for the normal push to try and update the HEAD, 
index, and workdir. instead of refusing the push, how about having it put 
the commits in the repository and then fail to change the HEAD, index, and 
workdir if any of them contain changes? (along with a warning that it's 
doing so).

this should be safe to do because it will only flag on the particular 
combination of events that will cause data loss rather than the broader 
prohibition of "don't push if there is a workdir" that affects legitimate 
uses as well

David Lang