{"thread":{"id":"64616","subject":"Different behaviour for --find-renames between git diff and git merge?","startedAt":"2025-12-12T18:04:04Z","lastAt":"2025-12-16T19:44:25Z","messageCount":6,"participants":["Luca Balsanelli","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"532086","messageId":"3742e7de-7d88-4e77-b711-9fed867a8c23@gmail.com","threadId":"64616","inReplyTo":null,"subject":"Different behaviour for --find-renames between git diff and git merge?","fromName":"Luca Balsanelli","fromEmail":"lucabalsanelli@gmail.com","sentAt":"2025-12-12T18:04:00Z","receivedAt":"2025-12-12T18:04:04Z","isPatch":false,"sender":{"key":"lucabalsanelli@gmail.com","avatar":null},"body":"Hi,\n\n   I'm scratching my head to understand why on the following case `git \ndiff` and `git merge` give a different interpretation about a rename.\n\n    git switch master\n    touch aaa\n    git add aaa\n    git commit -m 'aaa'\n\n    git switch -c branch\n    echo -en 'A\\nB\\nC\\n' > aaa\n    git add aaa\n    git commit -m 'A\\nB\\nC\\n > aaa'\n\n    git switch master\n    echo -en 'A\\nB\\n' > aaa\n    mkdir dir\n    mv aaa dir/\n    git add aaa dir/\n    git commit -m 'A\\nB\\n > aaa -> dir/'\n\nThe `|merge.renames` config variable is true. Changing `git diff \n--find-renames=50%` (the default) or `git merge -s ort -X \nfind-renames=50%` ||to something lower does not change the following.\n|\n\n`git diff` prints\n\n    diff --git a/aaa b/dir/aaa\n    similarity index 71%\n    rename from aaa\n    rename to dir/aaa\n    index bbd2b90..986ad36 100644\n    --- a/aaa\n    +++ b/dir/aaa\n    @@ -1,4 +1,3 @@\n      A\n      B\n    -C\n\n     that is the similarity index is 71% and it detects the rename.\n\n`git merge branch`, instead, gives\n\n    CONFLICT (modify/delete): aaa deleted in HEAD and modified in\n    branch.  Version branch of aaa left in tree.\n    Automatic merge failed; fix conflicts and then commit the result\n\nWhy it is that? I always supposed that the rename detection was the same \nfor `git diff`, `git merge`. Reading the documentation I do not find any \nhint why `git diff` and `git merge` are behaving differently.\n\nThanks,\n\nLuca Balsanelli\n\n"},{"id":"532113","messageId":"CABPp-BH80R4LJDRKQnPmh5Am_HAcCgxWiA8vRoN8LgLRUMz+JQ@mail.gmail.com","threadId":"64616","inReplyTo":"3742e7de-7d88-4e77-b711-9fed867a8c23@gmail.com","subject":"Re: Different behaviour for --find-renames between git diff and git merge?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-12-13T01:57:07Z","receivedAt":"2025-12-13T01:57:18Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Dec 12, 2025 at 10:06 AM Luca Balsanelli\n<lucabalsanelli@gmail.com> wrote:\n>\n> Hi,\n>\n>    I'm scratching my head to understand why on the following case `git\n> diff` and `git merge` give a different interpretation about a rename.\n\nI don't see any difference...\n\n>     git switch master\n>     touch aaa\n>     git add aaa\n>     git commit -m 'aaa'\n>\n>     git switch -c branch\n>     echo -en 'A\\nB\\nC\\n' > aaa\n>     git add aaa\n>     git commit -m 'A\\nB\\nC\\n > aaa'\n>\n>     git switch master\n>     echo -en 'A\\nB\\n' > aaa\n>     mkdir dir\n>     mv aaa dir/\n>     git add aaa dir/\n>     git commit -m 'A\\nB\\n > aaa -> dir/'\n>\n> The `|merge.renames` config variable is true. Changing `git diff\n> --find-renames=50%` (the default) or `git merge -s ort -X\n> find-renames=50%` ||to something lower does not change the following.\n> |\n>\n> `git diff` prints\n\nActually, it doesn't; more on that below...\n\n>\n>     diff --git a/aaa b/dir/aaa\n>     similarity index 71%\n\nDid you not follow your own recipe?  Maybe you inserted an extra space\nor left off the 'n' in 'echo -en' when you ran this?  The number\nshould have been 66%.\n\n>     rename from aaa\n>     rename to dir/aaa\n>     index bbd2b90..986ad36 100644\n>     --- a/aaa\n>     +++ b/dir/aaa\n>     @@ -1,4 +1,3 @@\n>       A\n>       B\n>     -C\n>\n>      that is the similarity index is 71% and it detects the rename.\n\nAt this point, if you actually run `git diff` you see the following:\n\n$ git diff\n$\n\ni.e. nothing.  I suspect you gave `git diff` additional arguments but\ndidn't tell us.  Let's look at a few options:\n\n$ git diff master~1 master\ndiff --git a/aaa b/aaa\ndeleted file mode 100644\nindex e69de29..0000000\ndiff --git a/dir/aaa b/dir/aaa\nnew file mode 100644\nindex 0000000..35d242b\n--- /dev/null\n+++ b/dir/aaa\n@@ -0,0 +1,2 @@\n+A\n+B\n$\n\nSo, on master, aaa was deleted, and dir/aaa was added.\n\n$ git diff master~1 branch\ndiff --git a/aaa b/aaa\nindex e69de29..b1e6722 100644\n--- a/aaa\n+++ b/aaa\n@@ -0,0 +1,3 @@\n+A\n+B\n+C\n$\n\nOn branch, aaa was modified.\n\n$ git diff branch master\ndiff --git a/aaa b/dir/aaa\nsimilarity index 66%\nrename from aaa\nrename to dir/aaa\nindex b1e6722..35d242b 100644\n--- a/aaa\n+++ b/dir/aaa\n@@ -1,3 +1,2 @@\n A\n B\n-C\n$\n\nSo, only if you diff the endpoints of the two branches do you see a\nrename; if you look from the merge base to either branch, there isn't\none.\n\n> `git merge branch`, instead, gives\n>\n>     CONFLICT (modify/delete): aaa deleted in HEAD and modified in\n>     branch.  Version branch of aaa left in tree.\n>     Automatic merge failed; fix conflicts and then commit the result\n\nYes, this exactly matches what diff showed above -- on HEAD (master),\n'aaa' was deleted, and on branch, 'aaa' was modified.\n\n> Why it is that? I always supposed that the rename detection was the same\n> for `git diff`, `git merge`. Reading the documentation I do not find any\n> hint why `git diff` and `git merge` are behaving differently.\n\nHope that helps...\n"},{"id":"532188","messageId":"d7135cd2-e577-4f96-8142-cd9c7cd6995d@gmail.com","threadId":"64616","inReplyTo":"CABPp-BH80R4LJDRKQnPmh5Am_HAcCgxWiA8vRoN8LgLRUMz+JQ@mail.gmail.com","subject":"Re: Different behaviour for --find-renames between git diff and git merge?","fromName":"Luca Balsanelli","fromEmail":"lucabalsanelli@gmail.com","sentAt":"2025-12-15T14:02:09Z","receivedAt":"2025-12-15T14:02:13Z","isPatch":false,"sender":{"key":"lucabalsanelli@gmail.com","avatar":null},"body":"On 13/12/25 02:57, Elijah Newren wrote:\n> On Fri, Dec 12, 2025 at 10:06 AM Luca Balsanelli\n> <lucabalsanelli@gmail.com> wrote:\n>> Hi,\n>>\n>> I'm scratching my head to understand why on the following case `git\n>> diff` and `git merge` give a different interpretation about a rename.\n> I don't see any difference...\n\nSorry, my email was not clear. There is still something that is not \nconvincing me though. I will reformulate my question at the end, after I \nreply 'inline' to all the (true) considerations. I consider myself \ndecently educated on git, but probably I still miss some understanding \nof the merge procedure.\n\n>> git switch master\n>> touch aaa\n>> git add aaa\n>> git commit -m 'aaa'\n>>\n>> git switch -c branch\n>> echo -en 'A\\nB\\nC\\n' > aaa\n>> git add aaa\n>> git commit -m 'A\\nB\\nC\\n > aaa'\n>>\n>> git switch master\n>> echo -en 'A\\nB\\n' > aaa\n>> mkdir dir\n>> mv aaa dir/\n>> git add aaa dir/\n>> git commit -m 'A\\nB\\n > aaa -> dir/'\n>>\n>> The `|merge.renames` config variable is true. Changing `git diff\n>> --find-renames=50%` (the default) or `git merge -s ort -X\n>> find-renames=50%` ||to something lower does not change the following.\n>> |\n>>\n>> `git diff` prints\n> Actually, it doesn't; more on that below...\n\nI forgot to specify that I was intending to diff the two heads, that is \n`master` and `branch`. So it was\n\ngit switch master\n\ngit diff branch\n\n>> diff --git a/aaa b/dir/aaa\n>> similarity index 71%\n> Did you not follow your own recipe? Maybe you inserted an extra space\n> or left off the 'n' in 'echo -en' when you ran this? The number\n> should have been 66%.\n\nI don't know what I did but there were additional newlines. So, yes, the \nsimilarity index is 66% (which is still above to the default 50% to \ndetect renames for both `git diff` and `git merge`).\n\n>> rename from aaa\n>> rename to dir/aaa\n>> index bbd2b90..986ad36 100644\n>> --- a/aaa\n>> +++ b/dir/aaa\n>> @@ -1,4 +1,3 @@\n>> A\n>> B\n>> -C\n>>\n>> that is the similarity index is 71% and it detects the rename.\n> At this point, if you actually run `git diff` you see the following:\n>\n> $ git diff\n> $\n>\n> i.e. nothing. I suspect you gave `git diff` additional arguments but\n> didn't tell us. Let's look at a few options:\n>\n> $ git diff master~1 master\n> diff --git a/aaa b/aaa\n> deleted file mode 100644\n> index e69de29..0000000\n> diff --git a/dir/aaa b/dir/aaa\n> new file mode 100644\n> index 0000000..35d242b\n> --- /dev/null\n> +++ b/dir/aaa\n> @@ -0,0 +1,2 @@\n> +A\n> +B\n> $\n>\n> So, on master, aaa was deleted, and dir/aaa was added.\n>\n> $ git diff master~1 branch\n> diff --git a/aaa b/aaa\n> index e69de29..b1e6722 100644\n> --- a/aaa\n> +++ b/aaa\n> @@ -0,0 +1,3 @@\n> +A\n> +B\n> +C\n> $\n>\n> On branch, aaa was modified.\n>\n> $ git diff branch master\n> diff --git a/aaa b/dir/aaa\n> similarity index 66%\n> rename from aaa\n> rename to dir/aaa\n> index b1e6722..35d242b 100644\n> --- a/aaa\n> +++ b/dir/aaa\n> @@ -1,3 +1,2 @@\n> A\n> B\n> -C\n> $\n>\n> So, only if you diff the endpoints of the two branches do you see a\n> rename; if you look from the merge base to either branch, there isn't\n> one.\n\nYes, the above is all true. As I said above, I forgot to specify the \nargument: `git switch master; git diff branch`.\n\n>> `git merge branch`, instead, gives\n>>\n>> CONFLICT (modify/delete): aaa deleted in HEAD and modified in\n>> branch. Version branch of aaa left in tree.\n>> Automatic merge failed; fix conflicts and then commit the result\n> Yes, this exactly matches what diff showed above -- on HEAD (master),\n> 'aaa' was deleted, and on branch, 'aaa' was modified.\n>\n>> Why it is that? I always supposed that the rename detection was the same\n>> for `git diff`, `git merge`. Reading the documentation I do not find any\n>> hint why `git diff` and `git merge` are behaving differently.\n> Hope that helps...\n\nI would expect that `git merge branch` would detect a rename and the \nconflict resolved automatically. The 'ort' strategy (the default one), \n\"can detect and handle merges involving renames.\" and the default \nsimilarity threshold is the same for `git diff` and `git merge`. I \nunderstand that the merge procedure involves finding a merge base, but \nstill the rename should be detected between the two heads.\n\nI was reading commit `90d43b07687fdc51d1f2fc14948df538dc45584b` of the \ngit source code (which I found using `git log --grep '--rename-empty'`). \nIt says (among other things)\n\nThis patch lets callers specify whether or not they interested in\nusing empty files as rename sources and destinations. The default is\n\"yes\", keeping the original behavior. It works by detecting the\nempty-blob sha1 for rename sources and destinations.\n\nIt is related, but I don't think it is relevant to this specific case. \nEven though the `git diff master~1 master` doesn't detect the rename \n(the content changed too much compared to the empty file or one was \nempty (although it says it defaults to include empty files as rename \nsource or destinarion)), the rename should be detected between the two \nheads, even when merging. I tried to read at 'git/diffcore-rename.c' but \nI'm not very good at C and it would require me a great effort to fully \nunderstand it.\n\nSo, why `git merge branch` is not detecting the rename and not resolving \nthe conflict automatically? Does it use a different diff machinery \ncompared to `git diff`?\n\n"},{"id":"532226","messageId":"CABPp-BH1qgQNHJzJZ05Ckru2PdYxRnWfQ3xVPrqGG5F56bX1aw@mail.gmail.com","threadId":"64616","inReplyTo":"d7135cd2-e577-4f96-8142-cd9c7cd6995d@gmail.com","subject":"Re: Different behaviour for --find-renames between git diff and git merge?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-12-16T00:57:37Z","receivedAt":"2025-12-16T00:57:50Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Dec 15, 2025 at 6:02 AM Luca Balsanelli\n<lucabalsanelli@gmail.com> wrote:\n>\n> On 13/12/25 02:57, Elijah Newren wrote:\n> > On Fri, Dec 12, 2025 at 10:06 AM Luca Balsanelli\n> > <lucabalsanelli@gmail.com> wrote:\n[...]\n> I would expect that `git merge branch` would detect a rename and the\n> conflict resolved automatically. The 'ort' strategy (the default one),\n> \"can detect and handle merges involving renames.\" and the default\n> similarity threshold is the same for `git diff` and `git merge`. I\n> understand that the merge procedure involves finding a merge base, but\n> still the rename should be detected between the two heads.\n\nNo, it should only detect renames between the merge-base and the\nheads.  The merge machinery should not diff the two heads directly;\nthat goes against how 3-way diff works.\n\n[...]\n> Even though the `git diff master~1 master` doesn't detect the rename\n> (the content changed too much compared to the empty file or one was\n> empty (although it says it defaults to include empty files as rename\n> source or destinarion)), the rename should be detected between the two\n> heads, even when merging. I tried to read at 'git/diffcore-rename.c' but\n> I'm not very good at C and it would require me a great effort to fully\n> understand it.\n>\n> So, why `git merge branch` is not detecting the rename and not resolving\n> the conflict automatically? Does it use a different diff machinery\n> compared to `git diff`?\n\nMerging never diffs the endpoints, and shouldn't either.  It basically\ndoes two diffs, each from the merge-base to the end-point in question.\n\nIf you only diffed the endpoints, and one side renamed file A->B, how\ndo you differentiate between A->B and B->A?  In other words, you may\nknow there was a rename, but you can't tell what it was renamed from\nand which filename should be the final one.  You can only tell if you\nlook at the merge-base and determine that the file started out named\nas A, and thus that B should be the final name.\n\nIf you only diffed the endpoints, and one side renamed file A->B,\nwhile the other side renamed A->C, you'd be misled into thinking this\nwas a normal rename (you'd only see e.g. B->C) and be unaware of the\nconflict, which is problematic.\n\nIf you only diffed the endpoints, and one side renamed file A->B,\nwhile the other side renamed C->B, by diffing the endpoints you can't\neven tell there's a rename; you simply have a file named B that was\ntotally rewritten.  But it gets subtly worse in special cases that\nmight really confuse end users: if they modified A or C on the sides\nof history that didn't rename those files, those changes would not be\npropagated and combined with the ultimate B, and they'd be left to\npick up the pieces and try to combine things.\n\nFurther, it's just semantically wrong to diff the endpoints because of\nthe underlying concept of a 3-way merge: If you were merging D & E and\nsimply diffed D & E to do so, you won't know whether differing lines\nwere added or removed by recent commits.  For example, you might\nnotice an \"import\" or \"include\" statement that one side has that the\nother doesn't.  But did one side add that import statement?  Or did\nthe other side remove it?  You can't tell by looking at the endpoints;\nyou have to compare the endpoints to the merge-base to find out which\nthings were added or removed.  So, fundamentally, a 3-way merge thinks\nin terms of diffing the merge-base to the endpoints, not diffing the\nendpoints.\n\n\nSo, in summary, no, merge does not use a different diff machinery.\nYou are just diffing the wrong commits to see what it sees.  Combine\nthat with the fact that you have a funny special case where both sides\ndrastically change the file in a way where the new versions happen to\nbe similar to each other while not similar to the original, causes the\nbehavior you are seeing.\n"},{"id":"532270","messageId":"61700785-5421-4fa8-8277-c0837b09a737@gmail.com","threadId":"64616","inReplyTo":"CABPp-BH1qgQNHJzJZ05Ckru2PdYxRnWfQ3xVPrqGG5F56bX1aw@mail.gmail.com","subject":"Re: Different behaviour for --find-renames between git diff and git merge?","fromName":"Luca Balsanelli","fromEmail":"lucabalsanelli@gmail.com","sentAt":"2025-12-16T13:15:08Z","receivedAt":"2025-12-16T13:15:17Z","isPatch":false,"sender":{"key":"lucabalsanelli@gmail.com","avatar":null},"body":"On 16/12/25 01:57, Elijah Newren wrote:\n>> Even though the `git diff master~1 master` doesn't detect the rename\n>> (the content changed too much compared to the empty file or one was\n>> empty (although it says it defaults to include empty files as rename\n>> source or destinarion)), the rename should be detected between the two\n>> heads, even when merging. I tried to read at 'git/diffcore-rename.c' but\n>> I'm not very good at C and it would require me a great effort to fully\n>> understand it.\n>>\n>> So, why `git merge branch` is not detecting the rename and not resolving\n>> the conflict automatically? Does it use a different diff machinery\n>> compared to `git diff`?\n> Merging never diffs the endpoints, and shouldn't either.  It basically\n> does two diffs, each from the merge-base to the end-point in question.\n>\n> If you only diffed the endpoints, and one side renamed file A->B, how\n> do you differentiate between A->B and B->A?  In other words, you may\n> know there was a rename, but you can't tell what it was renamed from\n> and which filename should be the final one.  You can only tell if you\n> look at the merge-base and determine that the file started out named\n> as A, and thus that B should be the final name.\n>\n> If you only diffed the endpoints, and one side renamed file A->B,\n> while the other side renamed A->C, you'd be misled into thinking this\n> was a normal rename (you'd only see e.g. B->C) and be unaware of the\n> conflict, which is problematic.\n>\n> If you only diffed the endpoints, and one side renamed file A->B,\n> while the other side renamed C->B, by diffing the endpoints you can't\n> even tell there's a rename; you simply have a file named B that was\n> totally rewritten.  But it gets subtly worse in special cases that\n> might really confuse end users: if they modified A or C on the sides\n> of history that didn't rename those files, those changes would not be\n> propagated and combined with the ultimate B, and they'd be left to\n> pick up the pieces and try to combine things.\n>\n> Further, it's just semantically wrong to diff the endpoints because of\n> the underlying concept of a 3-way merge: If you were merging D & E and\n> simply diffed D & E to do so, you won't know whether differing lines\n> were added or removed by recent commits.  For example, you might\n> notice an \"import\" or \"include\" statement that one side has that the\n> other doesn't.  But did one side add that import statement?  Or did\n> the other side remove it?  You can't tell by looking at the endpoints;\n> you have to compare the endpoints to the merge-base to find out which\n> things were added or removed.  So, fundamentally, a 3-way merge thinks\n> in terms of diffing the merge-base to the endpoints, not diffing the\n> endpoints.\n>\n>\n> So, in summary, no, merge does not use a different diff machinery.\n> You are just diffing the wrong commits to see what it sees.  Combine\n> that with the fact that you have a funny special case where both sides\n> drastically change the file in a way where the new versions happen to\n> be similar to each other while not similar to the original, causes the\n> behavior you are seeing.\n\nThank you. I understand.\n\nMoreover, deepening the rename topic actually made me forget something \nabout the merge topic. In fact, even if the rename was detected in some \nway or even if I didn't rename one side at all, the `git merge branch` \nwould still be unable to resolve the conflict automatically, since both \nwere modified in different ways, even if in similar ways. But similarity \nis not enough. This confounded me.\n\nIn the following example, I start from an empty file and I modify it on \none side of the history and move (rename) it on the other side. The \nrename between `branch` and the merge base is detected. So, can you tell \nme why in the following case the rename is not detected during the merge?\n\n    git switch -c master root\n\n    touch aaa\n    git add aaa\n    git commit -m 'aaa'\n\n    git switch -c branch\n    echo -ne 'A\\nB\\nC\\n' > aaa\n    git add aaa\n    git commit -m 'A\\nB\\nC\\n > aaa'\n\n    git switch master\n    mkdir dir\n    mv aaa dir/\n    git add aaa dir/\n    git commit -m 'aaa -> dir/'\n\n    git merge --no-edit branch\n\nSorry if I'm pedant and thank you in advance.\n\n"},{"id":"532307","messageId":"CABPp-BHTnP-3erFTJ23goreg=UJGWPwCwdN9LNKsVbB3Omjt9w@mail.gmail.com","threadId":"64616","inReplyTo":"61700785-5421-4fa8-8277-c0837b09a737@gmail.com","subject":"Re: Different behaviour for --find-renames between git diff and git merge?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-12-16T19:44:13Z","receivedAt":"2025-12-16T19:44:25Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Tue, Dec 16, 2025 at 5:15 AM Luca Balsanelli\n<lucabalsanelli@gmail.com> wrote:\n>\n[...]\n> In the following example, I start from an empty file and I modify it on\n> one side of the history and move (rename) it on the other side. The\n> rename between `branch` and the merge base is detected. So, can you tell\n> me why in the following case the rename is not detected during the merge?\n>\n>     git switch -c master root\n>\n>     touch aaa\n>     git add aaa\n>     git commit -m 'aaa'\n>\n>     git switch -c branch\n>     echo -ne 'A\\nB\\nC\\n' > aaa\n>     git add aaa\n>     git commit -m 'A\\nB\\nC\\n > aaa'\n>\n>     git switch master\n>     mkdir dir\n>     mv aaa dir/\n>     git add aaa dir/\n>     git commit -m 'aaa -> dir/'\n>\n>     git merge --no-edit branch\n\nThis is an interesting case where --[no-]rename-empty option applies\n(the same option you found a related commit for in a previous email in\nthis thread):\n\n$ git diff master~1 master\ndiff --git a/aaa b/dir/aaa\nsimilarity index 100%\nrename from aaa\nrename to dir/aaa\n\n$ git diff --no-rename-empty master~1 master\ndiff --git a/aaa b/aaa\ndeleted file mode 100644\nindex e69de29..0000000\ndiff --git a/dir/aaa b/dir/aaa\nnew file mode 100644\nindex 0000000..e69de29\n\nThe merge machinery runs with the equivalent of --no-rename-empty:\n\n$ git -C ~/floss/git grep rename_empty merge-ort.c\nmerge-ort.c:    diff_opts.flags.rename_empty = 0;\n\nThis comes from commit 4f7cb99ada26 (merge-recursive: don't detect\nrenames of empty files, 2012-03-22), and the commit message there\nexplains the rationale.  (The name of the option and how it is set has\nchanged since 2012, due to commit 0d1e0e7801bb (diff: make struct\ndiff_flags members lowercase, 2017-10-31)).  merge-ort copied that\nbehavior from merge-recursive.\n\nSo, although the merge machinery calls the same diff machinery that\n`git diff` uses, it does pass slightly different defaults.  (There's a\ncouple others too; I believe the differences include rename_empty,\nrename_limit, histogram vs myers, basename-guided similarity, and the\npossibility of cached renames in a sequence of commits being\nreapplied.  Users are unlikely to see any of these typically, though\nyou certainly did here.)\n"}]}