Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

2016-12-27 Thread Igor Djordjevic BugA
On 27/12/2016 18:27, Junio C Hamano wrote: > To see the problem with "check existing lines", it probably is > easier to extend the above example to start from a file with one > more line, like this: > > 1 > 3 > 4 > 5 > > and extend all the example patches to remove "4 " line

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

2016-12-27 Thread Junio C Hamano
Junio C Hamano writes: > Imagine that the project wants LF line endings, i.e. it considers > that a line with CRLF ending has an unwanted "whitespace" at the > end. Now, you start from this source file: > > 1 > 3 > 5 > > and a patch like this comes in: > >

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

2016-12-26 Thread Igor Djordjevic BugA
Hi Junio, and thanks for sharing your thoughts. You understood it pretty well, except the context "scope". Example does show a single line change, and a single line old/new comparison, but that is for simplicity sake of the initial example. What I was discussing about was the whole patch "hunk"

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

2016-12-25 Thread Junio C Hamano
Igor Djordjevic BugA writes: > In short -- git-apply warns on applying the patch with CRLF line endings > (new), considered whitespace errors, even when previous hunk version > (old) has/had that very same CRLF line endings, too, so nothing actually > changed in this

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

2016-12-25 Thread Igor Djordjevic BugA
On 26/12/2016 00:49, Igor Djordjevic BugA wrote: > This is a follow-up of a message posted at git-users Google group[1], > as the topic may actually be better suited for this mailing list > instead. If needed, some elaboration on the context can be found there, > as well as a detailed example

git-apply: warn/fail on *changed* end of line (eol) *only*?

2016-12-25 Thread Igor Djordjevic BugA
Hi to all, This is a follow-up of a message posted at git-users Google group[1], as the topic may actually be better suited for this mailing list instead. If needed, some elaboration on the context can be found there, as well as a detailed example describing the motive for the question itself (or