Thread (13 messages) flat view 13 messages, 6 authors, 2017-05-31

Re: [Bug] git branch -v has problems with carriage returns

From: Johannes Sixt <hidden>
Date: 2017-05-20 06:48:53

Am 19.05.2017 um 23:55 schrieb Atousa Duprat:
I have tried to repro this issue but git goes out of its way to store
the commit messages using unix end-of-line format.
I think that git itself cannot create a repo exhibiting this problem.
Here is a recipe to reproduce the error:

   git init
   git commit --allow-empty -m initial
   git branch crlf $(printf '%s\r\n' subject '' line3_long line4 |
        git commit-tree HEAD:)

The reason for the "bug" is obviously that a line having CR in addition 
to LF is not "an empty line". Consequently, the second line is not 
treated as a separator between subject and body, whereupon Git 
concatenates all lines into one large subject line. This strips the LFs 
but leaves the CRs in tact, which, when printed on a terminal move the 
cursor to the beginning of the line, so that text after the CRs 
overwrites what is already in the terminal.

This is just to give you a head start. I'm not going to look into this.

-- Hannes
quoted
If I do `git branch -v` with such a subject line somehow the third and
second line get combined before the hash. Example:

$ git branch -v
See merge request !XXXX temp space 84e18d22fd Merge branch
'feature-XXX' into 'develop'
# <begins with third line> <ending of seconds line (if longer than
third)> <commit hash (correct)> <subject line (correct)>

Before git v2.13.0 `git branch -v` worked completely normal.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help