On 11.11.2013 20:43, Stefan Beller wrote: > On 11.11.2013 20:37, Junio C Hamano wrote: >> Stefan Beller <stefanbeller@xxxxxxxxxxxxxx> writes: >> >>> I do have this global config >>> core.safecrlf=warn >>> regarding line endings. >> >> Oh, that sounds very suspicious. If the payload has CRLF, CR and LF >> mixed, that would immediately violate safecrlf, so failing the >> application sounds like the right thing to do. > > Not having read the man page, but copied this global config > from some '1000 git tips in 5 minutes' years ago, > I do expect a setting set to "warn" to actually not change the > program flow except some inserted prints with warnings. > >> >>> I was using 1.8.5.rc1.17.g0ecd94d >>> >>> Trying to understand the problem, >> >> Likewise. Thanks for chiming in. >> > > Looking at the file we have a mixture of LF/CR, LF only and CR only > ending the lines. The formatted patch does have the same file endings > on the respective line of that file here. > > I was trying to change just one line ending to 2 lines (LF CR -> LF LF) > with a hex editor, so there it becomes a smaller (and more debugable ) > patch. I also tried LF -> CR and CR -> LF, but none of these small > changes seem to work. > > Stefan > Just having looked at the CRLF conversion code of git, and then at the file again. This file seems to be a special nasty kind, as the number of LFs is equal to the number of CRs in the file (373 of 0x0a and 0x0d each), but only 343 occurences of LF strictly following a CR, so there are 30 CRs and 30 LFs. This shouldn't be as problematic as my first thought was, there is never a direct comparison of stats.cr to stats.lf in convert.c. The CR and LF count are only compared to either the crlf count or 0. Stefan
Attachment:
signature.asc
Description: OpenPGP digital signature