public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: "Torsten Bögershausen" <tboegi@web•de>
Cc: "Sokolov\,
	Konstantin \(ext\)" <konstantin.sokolov.ext@siemens•com>,
	"'git\@vger.kernel.org'" <git@vger•kernel.org>
Subject: Re: git blame swallows up lines in case of mixed line endings
Date: Mon, 23 Feb 2015 10:44:50 -0800	[thread overview]
Message-ID: <xmqqwq38tql9.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54E88BFA.9050900@web.de> ("Torsten Bögershausen"'s message of "Sat, 21 Feb 2015 14:45:30 +0100")

Torsten Bögershausen <tboegi@web•de> 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.

next prev parent reply	other threads:[~2015-02-23 18:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19 13:48 git blame swallows up lines in case of mixed line endings Sokolov, Konstantin (ext)
2015-02-21 13:45 ` Torsten Bögershausen
2015-02-23 11:50   ` AW: " Sokolov, Konstantin (ext)
2015-02-23 18:44   ` Junio C Hamano [this message]
2015-02-23 19:09     ` Sokolov, Konstantin (ext)
2015-02-23 20:27       ` Junio C Hamano

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=xmqqwq38tql9.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=konstantin.sokolov.ext@siemens$(echo .)com \
    --cc=tboegi@web$(echo .)de \
    /path/to/YOUR_REPLY

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox