git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Beller <stefanbeller@googlemail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ken Tanzer <ken.tanzer@gmail.com>,
	git@vger.kernel.org, Philip Oakley <philipoakley@iee.org>
Subject: Re: git rm / format-patch / am fails on my file: patch does not apply
Date: Mon, 11 Nov 2013 21:39:42 +0100	[thread overview]
Message-ID: <5281408E.10601@googlemail.com> (raw)
In-Reply-To: <5281336F.7070103@googlemail.com>

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On 11.11.2013 20:43, Stefan Beller wrote:
> On 11.11.2013 20:37, Junio C Hamano wrote:
>> Stefan Beller <stefanbeller@googlemail.com> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

  reply	other threads:[~2013-11-11 20:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11  2:39 git rm / format-patch / am fails on my file: patch does not apply Ken Tanzer
2013-11-11 19:04 ` Junio C Hamano
2013-11-11 19:15   ` Stefan Beller
2013-11-11 19:37     ` Junio C Hamano
2013-11-11 19:43       ` Stefan Beller
2013-11-11 20:39         ` Stefan Beller [this message]
2013-11-13  0:26   ` Ken Tanzer
2013-11-13 17:04     ` Junio C Hamano
2013-11-13 23:12       ` Philip Oakley
2013-11-14  7:26         ` Ken Tanzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5281408E.10601@googlemail.com \
    --to=stefanbeller@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ken.tanzer@gmail.com \
    --cc=philipoakley@iee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).