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.vul...@gmail.com> wrote: > 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
