On Fri, Aug 19, 2022 at 2:17 AM Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
