UPDATE:
The initial message (see below) got rejected because it wasn't text/plain, so meanwhile a few things happened.
I was reading the manual pages of gitattributes and saw the note
> When text=auto normalization is enabled in an existing repository, any text files containing CRLFs should be normalized......
indeed, running
> rm ...index && git reset && git add -u && git commit -m "normalize crlf"
fixed the initial problem, leaving me with a new QUESTION:
why "git rm -rf --cached . && git reset --hard HEAD" is NOT showing dirty files that need normalization, but "rm ....index && git reset" does?
INITIAL MESSAGE:
Hello
I am running "git cherry-pick <HASH>" from one maintenance branch B2 to another B1, where B2 is newer than B1, in a repository with .gitattributes containing
> * text=auto
You can see an excerpt of the output below. Files 2-3-4 were deleted/renamed in B2 (newer branch). It seems that git cherry-pick is trying to normalize the files, but it fails because the files don't exist in the newer branch.
Show 10 quoted lines
> warning: CRLF will be replaced by LF in file1.html. > The file will have its original line endings in your working directory. > error: addinfo_cache failed for path 'file2.txt' > error: addinfo_cache failed for path 'file3.xml' > error: addinfo_cache failed for path 'file4.js' > U file4.js > error: commit is not possible because you have unmerged files. > hint: Fix them up in the work tree, and then use 'git add/rm <file>' > hint: as appropriate to mark resolution and make a commit. > fatal: Exiting because of an unresolved conflict.
I have tried
> git cherry-pick --strategy=recursive -X=no-renormalize <HASH>
to no avail. At the moment, the only fix I can have is to remove "* text=auto" from .gitattributes
I mention that before the cherry-pick, the git status is clean.
I am not subscribed to the mailing list, so please keep me in CC
Thank you in advance, Andrei
-- andreineculau.com