Elijah Newren <newren@xxxxxxxxx> 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. -- 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