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

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

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.

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.