Elijah Newren <newren@xxxxxxxxx> writes: > I'm not sure I'm following well enough to answer any your question(s), > so I'll instead ask a few of my own: > * Are you referring to stage #2 and stage #3 of the old path or the > new path or one of each or both of each? If they moved the sole neighbouring file X/A to Y/A, while we added a new path to X/B, I would expect we'd have two blobs with the same content we added, one at X/B at stage #2 (because that is what we wanted to have) and the other at Y/B at stage #3 (that's their wish the heuristic is guessing). If it were the other way, the stages would be different. > * Would this be consistent with how normal renames behave? > and, as a partial answer to your question: The use of the three-way merge logic at the tree structure level, unlike the "because neighbours moved" heuristics, gives a more definite answer. We see that the contents in the original at path A (in the common ancestor version) is now at path B (with or without slight modification) in their tree, while we kept it at path A (again, with or without modification). Or vice versa. Either way, at the tree structure level, that is "one side changes, while the other side does not modify" which is resolved cleanly to "take the new path the side that modifies wants the file to have". So we do not need to use the stages to represent "these sides wants to place it at different paths, which one is correct?" Instead, we'd have stages #1 (common ancestor), #2 (ours) and #3 (theirs) all at path B (i.e. the cleanly resolved structural change conflict) to help the user reconcile content level conflicts (iff needed). > I would prefer to tell the user they can resolve the conflict with two > other commands. I'm currently thinking of something like these two: > git add $directory_renamed_path > git mv $directory_renamed_path $original_path [&& git add $original_path ?] > This pair assumes we write the working tree and index entries for > $directory_renamed_path and leave $original_path empty in both the > working tree and index. We could alternatively reverse that, with an > equivalent but swapped set of commands for resolution. Yeah, the final version may have difference in detail, but I think it is sensible to leave a state, from which the user can go in either direction, with a simple command or two, like the above one. >> ... With that >> attitude, we may be able to get rid of choice (a) altogether, which >> may make things a tad simpler. IOW, we assume the heuristics would >> suggest the right solution most of the time, just like we assume >> rerere gives a reasonable resolution most of the time, with a knob >> to accept the result blindly, together with hints to recover when >> heuristics makes mistakes. > > I like that analogy. I think that aligns well with my possible > conflict-resolution commands, and further answers the question about > whether to put the new path or the old path in the working tree and > index. > > However, we do need some form of choice (a) for commands which can't > provide accurate tree information, such as git-am. Yeah, if we are not even running the heuristics for that case (a), hence it is not sensible to expect to offer "if we were doing directory renames, this path might have gone to that other place", then I think I am fine with not giving any hint to change their mind (after all, they can "git reset --hard" and retry the merge, this time not using the non-default (a) mode). And keeping around the simplest "we do not even attempt to" (a) mode as another option is fine by me. Thanks.
