From: Martin Date: Mon, 26 Jul 2021 12:50:01 GMT Subject: Re: Files modified, even after: git reset --hard Message-ID: In-Reply-To: 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)