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. 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). Anyway...does that help explain what's going on?
