Re: Please undo "Use git-merge instead of git-resolve in git-pull"

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> Local changes are a problem ONLY IF THOSE LOCAL CHANGES INTERFERE WITH THE 
> MERGE.

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.