Rename detection fails on symlinked files

Rename detection fails on symlinked files

[Michal Suchánek]

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

ln -s somefile-renamed somefile
git add somefile
git commit --amend

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

Can the rename detection be fixed to detect symlinked files as well?

Thanks

Michal

Re: Rename detection fails on symlinked files

[Elijah Newren]

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.

> 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.

> 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?

Re: Rename detection fails on symlinked files

[Michal Suchánek]

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@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.
> 
> > 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.
> 
> > 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.

There is indeed something fishy going on:

git show -B100 (or any value of B, really)

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 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

Re: Rename detection fails on symlinked files

[Michal Suchánek]

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@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.
> 
> > 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.

No, there is no original file:

diff --git a/some file b/some file
deleted file mode 100644
index b649a9b..0000000
--- a/some file 
+++ /dev/null
@@ -1 +0,0 @@
-some text
\ No newline at end of file
diff --git a/some file b/some file
new file mode 120000
index 0000000..b649a9b
--- /dev/null
+++ b/some file 
@@ -0,0 +1 @@
+some text
\ No newline at end of file

See, the plain file and symlink is so different that changing the mode
to symlink is represented as removing a file, and adding a symlink. Not
same file mode change, not even a rename. The symlink is so different
from the file that it's completely unrelated, even with exactly same
content. Mode change to/from symlink always breaks, regardless of content and
the break rewrites setting.

diff --git a/some file b/some file
deleted file mode 100644
index b649a9b..0000000
--- a/some file 
+++ /dev/null
@@ -1 +0,0 @@
-some text
\ No newline at end of file
diff --git a/some file b/some file
new file mode 120000
index 0000000..b649a9b
--- /dev/null
+++ b/some file 
@@ -0,0 +1 @@
+some text
\ No newline at end of file
diff --git a/some other file b/some other file
new file mode 100644
index 0000000..b649a9b
--- /dev/null
+++ b/some other file   
@@ -0,0 +1 @@
+some text
\ No newline at end of file

And here we now have one removal and two additions of the same content,
no rename detected.

So git cannot agree with itself if symlink and plain file is actually
the same file or not. They are presented as comletely unrelated to the
user yet rename detection fails to detect the rename of the plain file
that is completely unrelated to the added symlink. That is the
discrepancy, and the bug.

Thanks

Michal