On Tue, Jun 17, 2025 at 10:44:23AM -0700, Elijah Newren wrote:
> Hi,
>
> On Tue, Jun 17, 2025 at 4:16 AM Michal Suchánek <msuchanek@xxxxxxx> wrote:
>
> I think your subject might be slightly misleading, and that a more
> accurate subject might be: Rename detection is not performed for files
> still present in the target version. Let me explain why and you can
> check if I'm understanding your problem setup correctly.
>
> > commit 5d51b10d8b5206ef5eeb9d214237b2ec2e0b789e (HEAD -> master)
> > Author: Michal Suchanek <msuchanek@xxxxxxx>
> > Date: Tue Jun 17 13:08:51 2025 +0200
> >
> > rename file
> >
> > diff --git a/somefile b/somefile-renamed
> > similarity index 100%
> > rename from somefile
> > rename to somefile-renamed
>
> So you've renamed a file, detected at the time you run git log -p.
>
> > ln -s somefile-renamed somefile
> > git add somefile
> > git commit --amend
>
> Here, you reintroduce the original file, as a symlink, and amend the commit.
>
> > commit 377d9bd045aed61c7be55482f3c98f8f9d04a33d (HEAD -> master)
> > Author: Michal Suchanek <msuchanek@xxxxxxx>
> > Date: Tue Jun 17 13:08:51 2025 +0200
> >
> > rename file
> >
> > diff --git a/somefile b/somefile
> > deleted file mode 100644
> > index a53032b..0000000
> > Binary files a/somefile and /dev/null differ
> > diff --git a/somefile b/somefile
> > new file mode 120000
> > index 0000000..fc49048
> > --- /dev/null
> > +++ b/somefile
> > @@ -0,0 +1 @@
> > +somefile-renamed
> > \ No newline at end of file
> > diff --git a/somefile-renamed b/somefile-renamed
> > new file mode 100644
> > index 0000000..a53032b
> > Binary files /dev/null and b/somefile-renamed differ
>
> If I'm understanding the behavior that bothers you, it doesn't seem to
> be related to symlinks. You could create any regular text file
> unrelated to the original somefile (or even introduce a submodule) and
> place it in somefile and amend the commit, and you'd see that the
> rename wasn't detected. For example, replace your `ln -s/git add/git
> commit --amend` sequence with
>
> $ echo content >somefile
> $ git add somefile
> $ git commit --amend
>
> and you'd see that there was no rename detected from the original
> somefile to the new somefile-renamed. By default, if the file is
> present in both the source and the destination, it is not involved in
> rename detection.
>
> > Can the rename detection be fixed to detect symlinked files as well?
>
> Symlink renames can be and are detected, by default. For example:
>
> $ ln -s somefile old-symlink
> $ git add old-symlink
> $ git commit -m old
> $ git mv old-symlink new-symlink
> $ git commit -m new
> $ git diff HEAD~1
> diff --git a/old-symlink b/new-symlink
> similarity index 100%
> rename from old-symlink
> rename to new-symlink
>
> But from your example, you're not renaming a symlink, so instead of
> "Can rename detection handle symlinked files?", your question really
> is more of "Can a renamed file be detected even when some other
> file/link/submodule is immediately placed where the renamed file used
> to be?"
>
> git assumes, by default, that a file which exists in both the source
> and destination are "related" and will only look for renames in
> deleted or added files. Allowing git to mark a file as both a delete
> and an add even when it's present in both the source and the target is
> the job of break detection, which is not turned on by default.
> Further, break detection and rename detection have a bug or two when
> used together (brought up on the mailing list by Junio some years
> ago), which might need to be fixed for your example to work as you
> expect if you try to turn on break detection.
There is indeed something fishy going on:
git show -B100 (or any value of B, really)
commit 377d9bd045aed61c7be55482f3c98f8f9d04a33d (HEAD -> master)
Author: Michal Suchanek <msuchanek@xxxxxxx>
Date: Tue Jun 17 13:08:51 2025 +0200
rename file
diff --git a/somefile b/somefile
deleted file mode 100644
index a53032b..0000000
Binary files a/somefile and /dev/null differ
diff --git a/somefile b/somefile
new file mode 120000
index 0000000..fc49048
--- /dev/null
+++ b/somefile
@@ -0,0 +1 @@
+somefile-renamed
\ No newline at end of file
diff --git a/somefile b/somefile-renamed
similarity index 100%
copy from somefile
copy to somefile-renamed
> Also, not sure how deep your interest in break detection goes, but
> merge-ort was written with some implicit assumptions that break
> detection is _not_ active. Trying to retrofit it to support break
> detection might take a significant chunk of work; and even if someone
> is motivated to make it work, it'd defeat the safety of every
> optimization added to it (making it orders of magnitude slower), and
> also tack on a significant performance penalty on top of all that
> (break detection is not cheap when at least one side of the merge has
> a significant number of files modified).
Does merge-ort at least refuse to run with break detection enabled?
This is mainly for examining changes, following a file trough history, and
such. When it comes to that there are other merge strategies besides ort so it
may not be completely hopeless trying to merge across renames, too.
Thanks
Michal
