AW: git blame swallows up lines in case of mixed line endings
- From
- Sokolov, Konstantin (ext) <konstantin.sokolov.ext@siemens.com>
- Date
- Feb 23, 2015, 11:50 UTC
- Message-ID
- <71BF70CE41AEE741896AF3A5450D86F11F2D20FD@DEFTHW99EH3MSX.ww902.siemens.net>
- In-Reply-To
- <54E88BFA.9050900@web.de>
It's not that I want to use CR as line ending. We just had to process a repository where it was the case. We use git blame as an automatic processing step in a bigger system. So if a line does not exist for git blame but it does exist for other parts of the system (which read the same file) we run into consistency problems.
-----Ursprüngliche Nachricht----- Von: Torsten Bögershausen [mailto:tboegi@web.de] Gesendet: Samstag, 21. Februar 2015 14:46 An: Sokolov, Konstantin (ext); 'git@vger.kernel.org' Betreff: Re: git blame swallows up lines in case of mixed line endings
On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:
Show 34 quoted lines
> Hi Folks, > > I encounter unexpected behavior in the following case: > > file content: > > line1<CR><LF> > line2<CR> > line3<CR><LF> > line4 > > This is what I get as console output (on Windows): > >> git blame -s file.txt > 7db36436 1) line1 > line3436 2) line2 > 7db36436 3) line4 > > This is the real content: > >> git blame -s file.txt > blame.txt > > blame.txt opened in Notepad++: > > 7db36436 1) line1 <CR><LF> > 7db36436 2) line2 <CR> > line3 <CR><LF> > 7db36436 3) line4 <LF> > > Admittedly, very stupid editors, such as Windows Notepad, cannot handle mixed line endings as well. But is this also the way git blame should behave? > > Kind regards > Konstantin >
Git (and other tools) do not handle a single CR as a line ending. A line ending in Git is either CRLF or LF.
A "mixed line ending" in Git sense is a mixture between CRLF and LF, but not a lone CR. (And in this sense it is the expected behavior)
Are you sure you want to use it, or is it a typo ?