Re: [PATCHv2 0/3] Fix unnecessary (mtime) updates of files during merge

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> We could fix this second testcase by recording stat information for
> files removed by make_room_for_directories_of_df_conflicts(), and
> then, if those files are reinstated at the end of conflict resolution
> (i.e. the directory of the D/F conflict went away during the merge),
> then call utime() to reset the modification times on those files back
> to what they originally were.

Which is a big Yuck.  I agree that we don't want to go there.

The real cause of the problem is that the code removes the files that
could potentially involved in conflict _way_ too early, and unfortunately
this is coming from the way merge-recursive tracks d/f conflicts, which is
to grab set of path that can potentially appear as directories by throwing
all directories into a single string list from both sides of the merge
(same for non directory paths using another single string list) upfront,
and after that point, it becomes very hard to tell if the potential
directory is on your (i.e. stage #2) side or on their side, and to make
things worse, it doesn't wait writing partial results out to the working
tree before it knows the result of the merge to say something intelligent
like "all these files under the directory will go away and we can safely
keep the file there".  Your earlier series, e.g. 2ff739f (merge-recursive:
New function to assist resolving renames in-core only, 2010-09-20), was a
step in the right direction, but we are not there yet while functions like
make_room_for_path() and make_room_for_directories_of_df_conflicts() are
used.

So I think it would need a lot major restructuring of the merge-recursive,
especially its d/f conflict logic, to fix the second one correctly.

Thanks.