public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Elijah Newren <newren@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Rename detection fails on symlinked files
Date: Thu, 25 Sep 2025 09:39:16 +0200	[thread overview]
Message-ID: <aNTxpDrfUKsbvkZt@kitsune.suse.cz> (raw)
In-Reply-To: <CABPp-BFdEn8rYu+FW+CdgrKNDUGBY9h6ePSH-vjYy-f_Pji0-Q@mail.gmail.com>

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

      parent reply	other threads:[~2025-09-25  7:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17 11:13 Rename detection fails on symlinked files Michal Suchánek
2025-06-17 17:44 ` Elijah Newren
2025-06-17 18:23   ` Michal Suchánek
2025-09-25  7:39   ` Michal Suchánek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aNTxpDrfUKsbvkZt@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox