Re: git blame swallows up lines in case of mixed line endings

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 23, 2015, 18:44 UTC
Message-ID: <xmqqwq38tql9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54E88BFA.9050900@web.de>

Torsten Bögershausen <tboegi@web.de> writes:

Show 10 quoted lines

> 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.

Show 6 quoted lines

>> 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.