True, sorry, and reverted.
* Regardless of whatever else, we could detect when there is
only one strategy applicable and bypass that check -- "reset
--hard" should never happen in that case and 'git pull -s
stupid' would regain the traditional behaviour and we should
probably make this the default for 'git pull'.
* Otherwise, if the user wants it to try multiple strategies, we
need to detect the local changes in the tree that _could_
interfere with the merge more precisely.
In order for that, we need to have a way to figure out the set
of paths that _could_ potentially be involved in the merge.
Once we have that set, we can just check if we have local
changes on those paths, and the "restoring to the pre-merge
state" currently done with "reset --hard" kludge could just
restore those paths from the pre-merge HEAD.
This is however harder than it sounds once we start allowing
renaming merges. If the ancestor had A/foo, you kept it and
have an addition of A/bar as a local change, and the head that
is being merged renames stuff in A/ to B/A/, it is more likely
than not that you would want to have A/bar moved to B/A/bar in
your merge result. Once we go this route, the only thing it
makes sense would be to make it responsibility for each merge
strategy to preserve before starting its work and to restore
after it has failed.
* I thought you do not multitask and wonder why you are merging
while you still have local changes, but that does not justify
this regression.
Junio C Hamano <junkio@cox.net>