Re: Files modified, even after: git reset --hard
- From
- Martin <git@mfriebe.de>
- Date
- Jul 26, 2021, 12:50 UTC
- Message-ID
- <abfb0196-ff4e-199a-6464-335abf514a63@mfriebe.de>
- In-Reply-To
- <fd2f2e6b-0ced-8eb7-b908-956b084f23c7@iee.email>
On 26/07/2021 12:39, Philip Oakley wrote:
Show 16 quoted lines
> 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.
Show 6 quoted lines
> 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)