{"thread":{"id":"38602","subject":"git blame swallows up lines in case of mixed line endings","startedAt":"2015-02-19T13:48:03Z","lastAt":"2015-02-23T20:27:51Z","messageCount":6,"participants":["Sokolov, Konstantin (ext)","Torsten Bögershausen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256351","messageId":"71BF70CE41AEE741896AF3A5450D86F11F2D1F46@DEFTHW99EH3MSX.ww902.siemens.net","threadId":"38602","inReplyTo":null,"subject":"git blame swallows up lines in case of mixed line endings","fromName":"Sokolov, Konstantin (ext)","fromEmail":"konstantin.sokolov.ext@siemens.com","sentAt":"2015-02-19T13:48:03Z","receivedAt":"2015-02-19T13:48:03Z","isPatch":false,"sender":{"key":"konstantin.sokolov.ext@siemens.com","avatar":null},"body":"Hi Folks,\n\nI encounter unexpected behavior in the following case:\n\nfile content:\n\nline1<CR><LF>\nline2<CR>\nline3<CR><LF>\nline4\n\nThis is what I get as console output (on Windows):\n\n> git blame -s file.txt\n7db36436 1) line1\nline3436 2) line2\n7db36436 3) line4\n\nThis is the real content:\n\n> git blame -s file.txt > blame.txt\n\nblame.txt opened in Notepad++:\n\n7db36436 1) line1 <CR><LF>\n7db36436 2) line2 <CR>\nline3 <CR><LF>\n7db36436 3) line4 <LF>\n\nAdmittedly, very stupid editors, such as Windows Notepad, cannot handle mixed line endings as well. But is this also the way git blame should behave?\n\nKind regards\nKonstantin\n"},{"id":"256466","messageId":"54E88BFA.9050900@web.de","threadId":"38602","inReplyTo":"71BF70CE41AEE741896AF3A5450D86F11F2D1F46@DEFTHW99EH3MSX.ww902.siemens.net","subject":"Re: git blame swallows up lines in case of mixed line endings","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-02-21T13:45:30Z","receivedAt":"2015-02-21T13:45:30Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:\n> Hi Folks,\n> \n> I encounter unexpected behavior in the following case:\n> \n> file content:\n> \n> line1<CR><LF>\n> line2<CR>\n> line3<CR><LF>\n> line4\n> \n> This is what I get as console output (on Windows):\n> \n>> git blame -s file.txt\n> 7db36436 1) line1\n> line3436 2) line2\n> 7db36436 3) line4\n> \n> This is the real content:\n> \n>> git blame -s file.txt > blame.txt\n> \n> blame.txt opened in Notepad++:\n> \n> 7db36436 1) line1 <CR><LF>\n> 7db36436 2) line2 <CR>\n> line3 <CR><LF>\n> 7db36436 3) line4 <LF>\n> \n> 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?\n> \n> Kind regards\n> Konstantin\n>\nGit (and other tools) do not handle a single CR as a line ending.\nA line ending in Git is either CRLF or LF.\n\nA \"mixed line ending\" in Git sense is a mixture between CRLF and LF, \nbut not a lone CR.\n(And in this sense it is the expected behavior)\n\nAre you sure you want to use it, or is it a typo ?\n"},{"id":"256501","messageId":"71BF70CE41AEE741896AF3A5450D86F11F2D20FD@DEFTHW99EH3MSX.ww902.siemens.net","threadId":"38602","inReplyTo":"54E88BFA.9050900@web.de","subject":"AW: git blame swallows up lines in case of mixed line endings","fromName":"Sokolov, Konstantin (ext)","fromEmail":"konstantin.sokolov.ext@siemens.com","sentAt":"2015-02-23T11:50:51Z","receivedAt":"2015-02-23T11:50:51Z","isPatch":false,"sender":{"key":"konstantin.sokolov.ext@siemens.com","avatar":null},"body":"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. \n\n-----Ursprüngliche Nachricht-----\nVon: Torsten Bögershausen [mailto:tboegi@web.de] \nGesendet: Samstag, 21. Februar 2015 14:46\nAn: Sokolov, Konstantin (ext); 'git@vger.kernel.org'\nBetreff: Re: git blame swallows up lines in case of mixed line endings\n\nOn 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:\n> Hi Folks,\n> \n> I encounter unexpected behavior in the following case:\n> \n> file content:\n> \n> line1<CR><LF>\n> line2<CR>\n> line3<CR><LF>\n> line4\n> \n> This is what I get as console output (on Windows):\n> \n>> git blame -s file.txt\n> 7db36436 1) line1\n> line3436 2) line2\n> 7db36436 3) line4\n> \n> This is the real content:\n> \n>> git blame -s file.txt > blame.txt\n> \n> blame.txt opened in Notepad++:\n> \n> 7db36436 1) line1 <CR><LF>\n> 7db36436 2) line2 <CR>\n> line3 <CR><LF>\n> 7db36436 3) line4 <LF>\n> \n> 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?\n> \n> Kind regards\n> Konstantin\n>\nGit (and other tools) do not handle a single CR as a line ending.\nA line ending in Git is either CRLF or LF.\n\nA \"mixed line ending\" in Git sense is a mixture between CRLF and LF, but not a lone CR.\n(And in this sense it is the expected behavior)\n\nAre you sure you want to use it, or is it a typo ?\n"},{"id":"256530","messageId":"xmqqwq38tql9.fsf@gitster.dls.corp.google.com","threadId":"38602","inReplyTo":"54E88BFA.9050900@web.de","subject":"Re: git blame swallows up lines in case of mixed line endings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-23T18:44:50Z","receivedAt":"2015-02-23T18:44:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:\n>> \n>> I encounter unexpected behavior in the following case:\n>> \n>> file content:\n>> \n>> line1<CR><LF>\n>> line2<CR>\n>> line3<CR><LF>\n>> line4\n\nYou can mark a file as <CRLF> terminated via attributes system and\nhave Git convert them to use <LF> as end-of-line when file contents\nare stored in Git (\"<LF> as end-of-line\" is the representation \"git\nblame\" uses internally).  Konstantin said \"on Windows\", and I guessed\ninitially that the lines are marked as such, but after looking at\nthe blame.txt output I am not sure.\n\nThat means the contents of the lines are:\n\n    First Line:  \"line1\"\n    Second Line: \"line2\" + CR + \"line3\"\n    Third Line:  \"line4\"\n\nor if CRLF conversion is not specified in Konstantin's repository:\n\n    First Line:  \"line1\" + CR\n    Second Line: \"line2\" + CR + CR + \"line3\" + CR\n    Third Line:  \"line4\" + CR\n\nEither way, that makes the observed behavior totally expected and\nunderstandable.\n\n>> This is what I get as console output (on Windows):\n>> \n>>> git blame -s file.txt\n>> 7db36436 1) line1\n>> line3436 2) line2\n>> 7db36436 3) line4\n\nAs printing CR moves the cursor to the beginning of line on many\nterminals, it is understandable to see the above output.  After\nprinting the first line, it will show \n\n    7db36436 2) line2\n\nand then go back to the leftmost column and then overwrite 7db3...\nwith \"line3\".\n\nEven though we have an option to mark <CR> alone as the end of line\nmarker, because the blamed content can go through the textconv\nfilter, it may be possible to define a textconv filter for the path\nvia the attribute system and convert such \"mixed line endings\"\ncontents to a series of <LF>-terminated lines.  That would split the\nsecond line in the original input into two lines and may produce\ndesired result.\n"},{"id":"256535","messageId":"71BF70CE41AEE741896AF3A5450D86F11F2D21EB@DEFTHW99EH3MSX.ww902.siemens.net","threadId":"38602","inReplyTo":"xmqqwq38tql9.fsf@gitster.dls.corp.google.com","subject":"AW: git blame swallows up lines in case of mixed line endings","fromName":"Sokolov, Konstantin (ext)","fromEmail":"konstantin.sokolov.ext@siemens.com","sentAt":"2015-02-23T19:09:21Z","receivedAt":"2015-02-23T19:09:21Z","isPatch":false,"sender":{"key":"konstantin.sokolov.ext@siemens.com","avatar":null},"body":"Thank you for going into the matter. I was not aware of the textconv filter. This is definitely a decent solution. But what exactly do you mean by \"Even though we have an option to mark <CR> alone as the end of line marker\"? Is there really such an option in Git or did you mean that it's possible in general (by changing the implementation)?\n\nKind Regards\nKonstantin\n\n-----Ursprüngliche Nachricht-----\nVon: Junio C Hamano [mailto:gitster@pobox.com] \nGesendet: Montag, 23. Februar 2015 19:45\nAn: Torsten Bögershausen\nCc: Sokolov, Konstantin (ext); 'git@vger.kernel.org'\nBetreff: Re: git blame swallows up lines in case of mixed line endings\n\nTorsten Bögershausen <tboegi@web.de> writes:\n\n> On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:\n>> \n>> I encounter unexpected behavior in the following case:\n>> \n>> file content:\n>> \n>> line1<CR><LF>\n>> line2<CR>\n>> line3<CR><LF>\n>> line4\n\nYou 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.\n\nThat means the contents of the lines are:\n\n    First Line:  \"line1\"\n    Second Line: \"line2\" + CR + \"line3\"\n    Third Line:  \"line4\"\n\nor if CRLF conversion is not specified in Konstantin's repository:\n\n    First Line:  \"line1\" + CR\n    Second Line: \"line2\" + CR + CR + \"line3\" + CR\n    Third Line:  \"line4\" + CR\n\nEither way, that makes the observed behavior totally expected and understandable.\n\n>> This is what I get as console output (on Windows):\n>> \n>>> git blame -s file.txt\n>> 7db36436 1) line1\n>> line3436 2) line2\n>> 7db36436 3) line4\n\nAs 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 \n\n    7db36436 2) line2\n\nand then go back to the leftmost column and then overwrite 7db3...\nwith \"line3\".\n\nEven 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\"\ncontents 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.\n\n"},{"id":"256545","messageId":"xmqqmw44s794.fsf@gitster.dls.corp.google.com","threadId":"38602","inReplyTo":"71BF70CE41AEE741896AF3A5450D86F11F2D21EB@DEFTHW99EH3MSX.ww902.siemens.net","subject":"Re: AW: git blame swallows up lines in case of mixed line endings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-23T20:27:51Z","receivedAt":"2015-02-23T20:27:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sokolov, Konstantin (ext)\" <konstantin.sokolov.ext@siemens.com>\nwrites:\n\n> Thank you for going into the matter. I was not aware of the textconv\n> filter. This is definitely a decent solution. But what exactly do you\n> mean by \"Even though we have an option to mark <CR> alone as the end\n> of line marker\"?\n\ns/have/do not have/; sorry for a false hope ;-)\n"}]}