git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Atousa Duprat <atousa.p@gmail.com>
Date
May 19, 2017, 21:55 UTC
Message-ID
<CA+izobvwRCwGEtpCbey=gFbCh9sHBb5xB1i1LpMG0JCUy0O2mQ@mail.gmail.com>
In-Reply-To
<CALKRkrxHNao6NY+-_UmznHdq29yVJJynu8Xx5M__YfK9UkdOAw@mail.gmail.com>
Sorry for the noise with previous response...

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.

Most helpful would be if you could create a mini repo using gitlab. All it would need is one file, two branches, and a merge. With that in hand, it should be pretty easy to track down the problem and fix git.

You mentioned that the previous version you were using was working fine, can you tell me which version that was? It'll help to narrow down the changes that could have affected the issue.

Thanks,
Atousa
On Tue, May 16, 2017 at 4:22 PM, Animi Vulpis <animi.vulpis@gmail.com> wrote:
Show 32 quoted lines
> Hi,
>
> I upgraded to git v2.13.0 and since then git branch -v has problems
> with carriage returns in subject lines.
>
> We are using gitlab (not the newest version). So this bug (It's about
> carriage returns in auto-generated merge messages (\r\n)) is not yet
> fixed in our version:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/31671
> That's were the carriage returns are coming from.
>
> In my specific case the auto-generated merge message has three lines
> with empty lines in between.
> So every line ends with `\r\n\r\n`
>
> 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.
>
> I was not able to create a minimal local example, because my manually
> created \r\n in commit messages were transformed into \n\n
>
> Please let me know if I can provide any more information that would be helpful.
>
> Cheers
Previous: Animi VulpisNext: Animi Vulpis
Message 2 of 21 in “[Bug] git branch -v has problems with carriage returns”
  1. Animi VulpisMay 16, 2017
  2. Atousa DupratMay 19, 2017
  3. Animi VulpisMay 19, 2017
  4. Johannes SixtMay 20, 2017
  5. Atousa DupratMay 31, 2017
  6. Stefan BellerMay 31, 2017
  7. Junio C HamanoJun 1, 2017
  8. ref-filter: treat CRLF as same as LF in find_subposDOAN Tran Cong Danh, May 21, 2017
  9. Junio C HamanoMay 22, 2017
  10. DOAN Tran Cong DanhMay 22, 2017
  11. Jeff KingMay 22, 2017
  12. Junio C HamanoMay 23, 2017
  13. Junio C HamanoMay 23, 2017
  14. Junio C HamanoMay 23, 2017
  15. ref-filter: treat CRLF as same as LF in find_subposDOAN Tran Cong Danh, May 21, 2017
  16. ref-filter: trim end whitespace in subjectDOAN Tran Cong Danh, May 22, 2017
  17. ref-filter: trim end whitespace in subjectDOAN Tran Cong Danh, May 22, 2017
  18. Johannes SixtMay 22, 2017
  19. Jeff KingMay 22, 2017
  20. Johannes SixtMay 22, 2017
  21. Atousa DupratMay 19, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.