Re: [PATCH 1/3] merge-tree -z: always show the original file name first

[Elijah Newren <newren@gmail.com>]

On Fri, Aug 19, 2022 at 2:17 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi all (and I guess in particular Elijah),
>
> On Fri, 19 Aug 2022, Johannes Schindelin via GitGitGadget wrote:
>
> > diff --git a/t/t4069-remerge-diff.sh b/t/t4069-remerge-diff.sh
> > index 35f94957fce..bc580a242ac 100755
> > --- a/t/t4069-remerge-diff.sh
> > +++ b/t/t4069-remerge-diff.sh
> > @@ -131,11 +131,12 @@ test_expect_success 'setup non-content conflicts' '
> >  test_expect_success 'remerge-diff with non-content conflicts' '
> >       git log -1 --oneline resolution >tmp &&
> >       cat <<-EOF >>tmp &&
> > +     diff --git a/file_or_directory b/file_or_directory
> > +     remerge CONFLICT (file/directory): directory in the way of file_or_directory from HASH (side1); moving it to file_or_directory~HASH (side1) instead.
> >       diff --git a/file_or_directory~HASH (side1) b/wanted_content
> >       similarity index 100%
> >       rename from file_or_directory~HASH (side1)
> >       rename to wanted_content
> > -     remerge CONFLICT (file/directory): directory in the way of file_or_directory from HASH (side1); moving it to file_or_directory~HASH (side1) instead.
> >       diff --git a/letters b/letters
> >       remerge CONFLICT (rename/rename): letters renamed to letters_side1 in HASH (side1) and to letters_side2 in HASH (side2).
> >       diff --git a/letters_side2 b/letters_side2
>
> I would have liked to avoid touching this file altogether, of course, but
> when I investigated, I came to the conclusion that while this patch still
> does not produce the best possible outcome for remerge diffs, it does
> improve upon the current situation.

No, this is a strict regression.  Those file headers corresponding to
the file/directory conflict (similarity index, rename from/to, and
CONFLICT) are all supposed to be grouped together in the same diff
header.  As to the names...

> The thing is, when mentioning that we had to rename `file_or_directory` to
> `file_or_directory~HASH (side1)` to be able to write the file because a
> directory of the same name already was in the way, I would actually have
> expected this to come under the diff header
>
>         diff --git a/file_or_directory b/file_or_directory~HASH (side1)
>
> Previously, it was under the header
>
>         diff --git a/file_or_directory~HASH (side1) b/wanted_content
>
> and with this patch it is under
>
>         diff --git a/file_or_directory b/file_or_directory
>
> which is still not ideal: It mentions only the original file name, not the
> munged one.

The point of remerge-diff is to show how a user modifies from the
auto-merged state to the final merge commit.  As such, the filenames
from before the merge starts are irrelevant; the only two relevant
things are the filename at the end of the automatic merge, and the
filename recorded in the commit.

In particular, for the case here, upon "git merge $BRANCH" the merge
would have stopped with a file named "file_or_directory~HASH\ (side1)"
present in the working copy[1].  The user resolved it via renaming
that file to "wanted_content".  As such, the first and third options
you list are incorrect, and the second one -- from the behavior
previous to your patch -- is correct.


[1] Technically, "git merge $BRANCH" would have used "HEAD" rather
than "HASH (side1)", but that's only because at the time of invocation
of git merge, HEAD would have been a very specific commit.  The same
isn't true of HEAD when the user runs `git log --remerge-diff` at some
very different time, so we opt to replace "HEAD" with something more
meaningful for readers of the diff when running --remerge-diff.