Torsten Bögershausen <tboegi@xxxxxx> writes:
> On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:
>>
>> I encounter unexpected behavior in the following case:
>>
>> file content:
>>
>> line1<CR><LF>
>> line2<CR>
>> line3<CR><LF>
>> line4
You can mark a file as <CRLF> terminated via attributes system and
have Git convert them to use <LF> as end-of-line when file contents
are stored in Git ("<LF> as end-of-line" is the representation "git
blame" uses internally). Konstantin said "on Windows", and I guessed
initially that the lines are marked as such, but after looking at
the blame.txt output I am not sure.
That means the contents of the lines are:
First Line: "line1"
Second Line: "line2" + CR + "line3"
Third Line: "line4"
or if CRLF conversion is not specified in Konstantin's repository:
First Line: "line1" + CR
Second Line: "line2" + CR + CR + "line3" + CR
Third Line: "line4" + CR
Either way, that makes the observed behavior totally expected and
understandable.
>> This is what I get as console output (on Windows):
>>
>>> git blame -s file.txt
>> 7db36436 1) line1
>> line3436 2) line2
>> 7db36436 3) line4
As printing CR moves the cursor to the beginning of line on many
terminals, it is understandable to see the above output. After
printing the first line, it will show
7db36436 2) line2
and then go back to the leftmost column and then overwrite 7db3...
with "line3".
Even though we have an option to mark <CR> alone as the end of line
marker, because the blamed content can go through the textconv
filter, it may be possible to define a textconv filter for the path
via the attribute system and convert such "mixed line endings"
contents to a series of <LF>-terminated lines. That would split the
second line in the original input into two lines and may produce
desired result.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html