From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.6 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id A66BC1F8C6 for ; Sun, 25 Jul 2021 15:41:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231302AbhGYPA3 (ORCPT ); Sun, 25 Jul 2021 11:00:29 -0400 Received: from smtprelay04.ispgateway.de ([80.67.18.16]:58823 "EHLO smtprelay04.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231215AbhGYPA2 (ORCPT ); Sun, 25 Jul 2021 11:00:28 -0400 Received: from [87.152.157.21] (helo=[192.168.2.202]) by smtprelay04.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1m7gDF-0003AP-O4 for git@vger.kernel.org; Sun, 25 Jul 2021 17:38:45 +0200 Subject: Re: Files modified, even after: git reset --hard From: Martin To: git@vger.kernel.org References: Message-ID: <4e9b54b4-8e40-7fd3-ae65-d33390f3af43@mfriebe.de> Date: Sun, 25 Jul 2021 17:40:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Df-Sender: bWVAbWZyaWViZS5kZQ== Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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. 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?