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. > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
