desktop: unable to parse commit because commit message contains ASCII delimiter characters

Description

When I open GitHub Desktop this error appears and keeps popping up:

screenshot 2019-02-13 at 10 19 36

The second part of the error message is a partial of a commit comment. The full commit looks like this:

commit <COMMIT_SHA>
Author: <Author Name> <HiddenName@users.noreply.github.com>
Date:   Fri Feb 8 14:50:24 2019 +0100

    Set queue_sid based on looked up queue (#546)

    Set queue_sid based on looked up queue
    Params sent by Twilio differ from usecase to usecase, so we need to make sure that a `^]queue_sid`^_ is always set, no matter how the call ended up in the queue.

This error also pops up whenever I click on the History tab or change the Mac OS Desktop to the one where GitHub Desktop is open.

Version

GitHub Desktop: 1.6.1

Operating system: Mac OS 10.14.2

Steps to Reproduce

I tried to reproduce it but this seems to only happen if another author commits with these characters in the commit message. Reproducing it locally wasn’t possible for me. Since this is a private repo I cannot share it with you.

Expected Behavior

No error message.

Actual Behavior

Error message keeps popping up.

Additional Information

Logs

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 3
Comments: 16 (10 by maintainers)

Most upvoted comments

Because of this popup, I am unable to use github desktop. Other git clients work fine though.

muhammadahmadsaeed on Sep 15, 2020

Hello? Anyone here? Any plans to fix this? As was pointed out above, you’re parsing the string incorrectly, Can I trouble you to possibly parse it correctly?

I hate to play grumpy old man here, but you’re parsing a string I don’t control, from a file I don’t control, and you’re doing it wrong. I can’t even guess at how to work around such a thing, much less fix it.

wrzwicky on Nov 29, 2019

Bumping this up to priority-2 because I see this error inside getCommits which is often called. I’ve also been able to trigger the issue while the repository is tracked in Desktop but not the selected one. This means the repository is unusable if you have this sort of corruption.

I’d love to size up the work required to fix this, given how fiddly the getCommits code is. Going to spend some time to end the working week looking into this and report back.

shiftkey on Feb 15, 2019

@ospaarmann please leave it up there for the moment. Once we’ve confirmed a fix and added a regression test we’ll let you know that it’s safe to cleanup.

shiftkey on Feb 14, 2019