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.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,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 A96CB1F8C6 for ; Mon, 26 Jul 2021 12:50:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234116AbhGZMJf (ORCPT ); Mon, 26 Jul 2021 08:09:35 -0400 Received: from smtprelay04.ispgateway.de ([80.67.18.16]:21335 "EHLO smtprelay04.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234031AbhGZMJe (ORCPT ); Mon, 26 Jul 2021 08:09:34 -0400 Received: from [84.163.73.49] (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 1m801O-0008SJ-Eh; Mon, 26 Jul 2021 14:47:50 +0200 Subject: Re: Files modified, even after: git reset --hard To: Philip Oakley , Chris Torek Cc: Git List References: <4e9b54b4-8e40-7fd3-ae65-d33390f3af43@mfriebe.de> <04f3b300-3ccf-c91b-6406-6a998b473a24@mfriebe.de> <070f7f5e-0e6c-2edc-1403-9265c810df17@mfriebe.de> From: Martin Message-ID: Date: Mon, 26 Jul 2021 14:50:01 +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-Language: en-GB Content-Transfer-Encoding: 8bit X-Df-Sender: bWVAbWZyaWViZS5kZQ== Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 26/07/2021 12:39, Philip Oakley wrote: > On 26/07/2021 02:34, Martin wrote: >> I figured that is the reason why they show modified. >> >> Not a problem. Until I am in the middle of a rebase, and i cannot run >> (after a conflict) >>   git rebase --continue >> >> The modified files are not part of the original series of commits. >> they are just random files from somewhere else in the tree. >> I can not reset/restore them. >> So I must now "git add" files entirely unrelated to continue rebasing. >> Well or apparently change my config for the duration of the rebase. > > Is this 'mid-rebase' the core case for the 'Files modified' problem? - > does it happen at other times (excepting maybe cherry-pick) > So far yes. Potentially, not yet tested, "git bisect" could be affected. That would also be a problem. And yes, when rebase failed, cherry pick would also fail. I did not see a "force" option for either of them, to ignore a dirty worktree. > i.e. you are rebasing a series of commits where some files had 'old' > line endings in the repository, but your current line ending setting > wants the line endings in those un-related, un-changed files to change > their line endings, and the rebase command can't cope with these > incidental differences? > I had a series of errors. Some of the errors, are indeed that I can not continue after resolving conflicts, because I can not clean the worktree. (I guess I could set up a .git/info/gitattribute to mark the files as binary, and remove it again after the rebase. But that is not a desirable solution) As a once off I also got an error: add_cacheinfo failed One branch really could not be rebase by any means. But it was a single commit, so I copied the files. I did "git replace" now for lots of those files. But some commits had "modified files" that appear to have the correct line ending in the repro (git add --renormalize did not add changes to be committed / the file is added, but commit says 0 lines changed, and the issue remains). So for those I have no way to get rid of yet. Those none-line ending issues existed already before I started to git replace. I did not replace commits, but only the blobs for the file in question (had to find several such blobs, per commit series)