From: Martin <git@mfriebe.de>
Date: Sun, 25 Jul 2021 17:48:52 GMT
Subject: Re: Files modified, even after: git reset --hard
Message-ID: <04f3b300-3ccf-c91b-6406-6a998b473a24@mfriebe.de>
In-Reply-To: <4e9b54b4-8e40-7fd3-ae65-d33390f3af43@mfriebe.de>

On 25/07/2021 17:40, Martin wrote:
> On 25/07/2021 17:04, Martin wrote:
>> I have some files, that will show up modified. Always.
>>
>> If I just switch to a commit, with clean worktree before, then those 
>> files will be modified.
>>
> ...
>> But I *suspect* that the blob contains either CrLf, or mixed 
>> line-endings.
>
> Maybe git replace?
> I figure if I do not replace the commit objects, but only the blobs to 
> which they point. Then all commits should keep their hashes. (so 
> references to any commit by hash would remain working)
>
> But it's thousands of commits, between the introduction of the issue, 
> and the commit where it's fixed.


Actually, git replace has a weird effect.

so I have "commit A" introducing the problem. Then many commits until 
"commit Y" fixing it.

If I do
switch -f --detach A
git add --renormalize the_file
git commit -m foo
git show   // get the new blob for the file
git show A  // get the old blob for the file
git replace  old_blob  new_blob

switch -f --detach A

Then "the_file" is still shown as modified.
Only
   git diff the_file
now returns empty
(where as before it returned the entire file)

On the plus side
   switch -f --detach B
has the same change, still modified, but no diff.
So one replace would solve the entire 1000 commits that are currently 
affected

Any idea, what causes the "modified" after the replace?