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

From: Martin <git@mfriebe.de>
Date: Jul 25, 2021, 15:40 UTC
Message-ID: <4e9b54b4-8e40-7fd3-ae65-d33390f3af43@mfriebe.de>
In-Reply-To: <dd4aca2c-9ca2-e489-d78f-9d2a5580f1a5@mfriebe.de>

On 25/07/2021 17:04, Martin wrote:

Show 5 quoted lines

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

Also, if that is the case, what can I do to resolve the issue? The file has been fixed in the meantime. It is about the old commits....

filter branch is not an option. All commit hashes must be kept. No force pushes to the repro...

That also means I can not use .gitattribute, because I could not amend it for the old revisions. I might be able to use my local $GIT_DIR/info/attributes. But then I risk to make new commits to that file, and introduce new wrong 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.
So I guess I need to create as many new blobs, and replacement entries.
- Is that practical? How does git perform with such many replacements
- Is there an easy way to create them?

Are there other, better solutions?