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

On 26/07/2021 12:39, Philip Oakley wrote:

On 26/07/2021 02:34, Martin wrote:

quoted

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)