Re: Files modified, even after: git reset --hard

From: Martin <git@mfriebe.de>
Date: Jul 25, 2021, 17:48 UTC
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:

Show 17 quoted lines

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