Re: [PATCH] git-mv: improve error message for conflicted file

>
> Elijah Newren <newren@gmail.com> writes:
>
> > Or, even better, make ce_stage(ce) not be an error; see
> > https://lore.kernel.org/git/xmqqk1ozb6qy.fsf@gitster-ct.c.googlers.com/.
>
> 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.

> [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.