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
--
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
