Re: Rename detection fails on symlinked files
Hi,
On Tue, Jun 17, 2025 at 4:16 AM Michal Suchánek <msuchanek@suse.de> 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.
Show 10 quoted lines
> commit 5d51b10d8b5206ef5eeb9d214237b2ec2e0b789e (HEAD -> master)
> Author: Michal Suchanek <msuchanek@suse.de>
> 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.
Show 22 quoted lines
> commit 377d9bd045aed61c7be55482f3c98f8f9d04a33d (HEAD -> master)
> Author: Michal Suchanek <msuchanek@suse.de>
> 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?
Michal Suchánek