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@xxxxxx] Gesendet: Samstag, 21. Februar 2015 14:46 An: Sokolov, Konstantin (ext); 'git@xxxxxxxxxxxxxxx' Betreff: Re: git blame swallows up lines in case of mixed line endings On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote: > 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 ? -- 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