Elijah Newren <newren@xxxxxxxxx> writes: > Or, even better, make ce_stage(ce) not be an error; see > https://lore.kernel.org/git/xmqqk1ozb6qy.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/. Hmph, I actually am not convinced with that one, even though I know I wrote it, I do not think I had thought things through before I did. It may make sense in a narrow special case where there is a single entry at a higher stage to rename it to the destination path and drop it down to stage #0, but I do not think of a good behaviour for more general cases. What should happen, for example, if two or more entries at higher stages exist for the path being moved? Renaming all of them to the destination path without changing their stage number may make more sense [*1*]. At least, that solution still lets the user to choose object at which stage [*2*] to use in the final resolution. Now, if we define that "git mv src dst", when 'src' is a conflicted path, moves the working tree file src to dst at the same time moves all the higher stage entries for 'src' to 'dst' while retaining their stage number, what does the degenerate case of having only one such entry look like? You start from the state where you have $that_path at stage #3, "git mv $that_path $over_there" would put you in the state where you have the same contents at $over_there and at stage #3. If you want to just take "their" contents as the resolution, "git add $over_there" after doing that "git mv" would let you record the resolution, so it does not look too bad. It would also be a handy way to recover from a mistake made by "directory level rename" heuristics. Instead of resolving the content-level conflicts at the wrong path and then moving that resolved result to the right path, you can first correct the wrong path by moving the conflicted whole to the right path and then perform the content-level conflict resolution. The advantage of the latter is obvious. You have to do two things (rename and edit) and with the former way of doing 'edit' first and then 'rename', after resolving the conflict and adding the result at the wrong path, "git ls-files -u" or "git status" no longer help you remember that the path still needs to be moved. Instead, you can move first and "git ls-files -u" would still remember that even after the move you still need to deal with content-level conflicts. Anyway, I think the "separate missing entry and conflicted entry when issuing an error message" is a strict improvement. [Footnotes] *1* Of course, the "D/F conflicts are issue only among the entries at the same stage" and other usual rules apply when we check if the move of these higher stage entries is possible. I am not sure if the low-level API functions like rename_index_entry_at() are prepared to deal with higher stage entries, though, so this may be a nontrivial amount of new work. It is unclear to me if it is worth doing. *2* Actually, "the object at stage #1 for conflicted path P" is a wrong thing to say. The index is designed to hold multiple stage #1 entries at the same path so that it can express the case where there are more than one common ancestors, and multiple stage #3 entries to express an octopus merge in progress. The notation to name the object in the index punts and does not let you say "git diff :1.0:path :1.1:path" to compare the first and the second common ancestor versions of path, though it probably should if we wanted to be consistent.
