Johannes Schindelin [off-list ref] writes:
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
Isn't there one thing we can do still? If we use CRLF for the
marker lines when the content is already mixed, I'd think it would
help Notepad (not necessary for Notepad2 or Wordpad IIUC) by making
sure that they can see where the marker lines end correctly.
I do not care too deeply about this; just throwing it out as a
possibility to help Windowsy folks a bit more.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Yeah, this is tricky, and from the same "helping Notepad that
concatenates lines with LF-only" perspective I should perhaps be
suggesting to use CRLF in such a case, too, but I would say we
should not do so. Three variants of a LF-only file may have
conflict at the incomplete last line, and if we only look at their
"no EOL"-ness and decide to add CRLF to the result, that would be
irritatingly wrong.
Hi Junio,
On Mon, 25 Jan 2016, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
Isn't there one thing we can do still? If we use CRLF for the
marker lines when the content is already mixed, I'd think it would
help Notepad (not necessary for Notepad2 or Wordpad IIUC) by making
sure that they can see where the marker lines end correctly.
Not sure. You might end up with a very long line (containing plenty of LF
"characters") and the conflict marker *at the end* of said line, with a
CR/LF after it. I would not call that particularly helpful.
Seeing as we really cannot do anything in this case, I thought it would be
a good idea to avoid trying (and failing) to be smart here.
quoted
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Yeah, this is tricky, and from the same "helping Notepad that
concatenates lines with LF-only" perspective I should perhaps be
suggesting to use CRLF in such a case, too, but I would say we
should not do so. Three variants of a LF-only file may have
conflict at the incomplete last line, and if we only look at their
"no EOL"-ness and decide to add CRLF to the result, that would be
irritatingly wrong.
Oh, but there is the fall-back to the first line. So if we have three
variants of an LF-only file, the logic will figure out that LF-only
end-of-lines are to be used.
So the *only* case where we really have to pick and choose is when all
three files contain only one (or no) line that is not terminated by a line
feed.
I briefly considered to choose EOL_NATIVE in that case, but I really do
not like that unnecessary deviation from Linux Git.
Ciao,
Dscho
On Tue, Jan 26, 2016 at 1:04 AM, Johannes Schindelin
[off-list ref] wrote:
Not sure. You might end up with a very long line (containing plenty of LF
"characters") and the conflict marker *at the end* of said line, with a
CR/LF after it. I would not call that particularly helpful.
Seeing as we really cannot do anything in this case, I thought it would be
a good idea to avoid trying (and failing) to be smart here.
Nicely and clearly explained; thanks, and I agree with your reasoning.