[PATCH] merge-recursive: tweak magic band-aid

Running checks against working tree (e.g. lstat()) and causing changes to working tree (e.g. unlink()) while building a virtual ancestor merge does not make any sense. Avoid doing so.

This is not a real fix; it is another magic band-aid on top of another band-aid we placed earlier.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * This does not fix the "even though we have local change in the working
   tree, we do have a clean index entry for that path that happens to be
   the one we renamed, and they didn't" case this message responds to, it
   does seem to fix the real-life breakage I saw when I merged 'maint' to
   'master' yesterday, admittedly in a clean working tree.

   merge-recursive is riddled with places that touch/inspect working tree
   when it shouldn't, and it is beyond salvage without a major refactoring
   in its current shape, so this magic band-aid should do for now.

   Generally speaking, the only valid kinds of accesses a merge strategy
   is allowed are:

   (1) to compare the working tree file with our original index entry to
       see if it has local changes. This should be done only for paths
       that the index entry of the merge result is different from the
       current one and the working tree file needs updating.  We need this
       check because the merge must not lose such local changes when we
       checkout the merge result. This check could use lstat(2) as part of
       ce_match_stat() from read-cache.c; or

   (2) to make sure there is no file that was not tracked in our original
       index in the working tree at the path that the result of the merge
       needs to create a file or a directory. We need this check because
       the merge must not lose such an untracked file when we checkout the
       merge result. This check would use lstat(2), as part of
       checkout_entry() from entry.c; or

   (3) when the result of the merge needs to create a file at a path and
       the working tree has a directory at the path, to make sure that the
       contents of the directory does not have any locally modified files
       relative to our original index, or untracked-and-unignored files.
       We need this check because the merge must be able to "rm -r" such a
       directory safely in order to checkout the merge result.

   As a special case, a file missing from the working tree is considered
   unmodified for the purpose of (1). IOW, removal of a path from the
   working tree without touching the index is considered a local change
   that we are willing to lose during a merge. This is to support a
   workflow (or a Porcelain script) that merges commits in a fresh
   temporary directory, e.g. this sequence

	cd_to_toplevel
	mkdir tmp_merge
        cd tmp_merge
        export GIT_DIR=../.git
        git read-tree pu ;# the branch may not be related to the current one
        git merge-resolve $(git merge-base pu topic) -- pu topic

   would start from an empty temporary merge directory, check out only the
   paths that were involved in the merge, potentially leaving conflict
   markers in them, and allows the user to resolve them, without touching
   the real working tree or the current branch. The resulting index can be
   written to a tree object to record the result of the merge.

 merge-recursive.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)