cherry-pick -Xrenormalize fails with formerly CRLF files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm working with a repo that used to be all CRLF. At some point it was changed to all LF, with `text=auto` in .gitattributes for the sake of Windows devs. I'm on Linux and have never touched any twiddles relating to line endings. I'm trying to cherry-pick some commits from before the switchover.

Straightforward cherry-picking causes entire files at a time to conflict, which I've seen before when switching from tabs to spaces. So I tried -Xrenormalize and got:

    fatal: CRLF would be replaced by LF in [path]

The error comes from check_safe_crlf, which warns if checksafe is CRLF_SAFE_WARN and dies if it's (presumably) CRLF_SAFE_FAIL. The funny thing is that it's CRLF_SAFE_RENORMALIZE.

I don't know what the semantics of this value are, but the caller (crlf_to_git) explicitly checks for CRLF_SAFE_RENORMALIZE and changes it to CRLF_SAFE_FALSE instead. But that check only happens if crlf_action is CRLF_AUTO*, and for me it's CRLF_TEXT_INPUT.

I moved the check to happen regardless of the value of crlf_action, and at least in this case, git appears to happily do the right thing. So I think this is a bug, but line endings are such a tangle that I'm really not sure. :)

The repository in question is ZDoom: https://github.com/rheit/zdoom
I'm trying to cherry-pick commits from the 3dfloors3 branch (e.g., 9fb2daf58e9d512170859302a1ac0ea9c2ec5993) onto a slightly outdated master, 6384e81d0f135a2c292ac3e874f6fe26093f45b1.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]