Re: A little mystery - crash caused by empty commit message.
From: Jeff King <hidden>
Date: 2016-06-15 22:46:08
On Tue, Feb 10, 2009 at 12:15:54PM +0100, Tor Arvid Lund wrote:
quoted hunk ↗ jump to hunk
Then I tried copying the repository to a linux box and tried gdb there. Much better. strchr(line, '\n') is called in pretty.c in the get_header function. For one of the commits, the 'line' parameter was NULL, so I managed to make it not crash with this little patch:diff --git a/pretty.c b/pretty.c index 8d4dbc9..1b2d097 100644 --- a/pretty.c +++ b/pretty.c@@ -230,6 +230,8 @@ static char *get_header(const struct commit*commit, const char *key) const char *line = commit->buffer; for (;;) { + if (line == NULL) + return NULL; const char *eol = strchr(line, '\n'), *next; if (line == eol)
Hmm. I can't reproduce the crash here with an empty commit message. I tried: mkdir repo && cd repo && git init && touch file && git add . && tree=`git write-tree` commit=`git commit-tree $tree </dev/null` git update-ref HEAD $commit git log Are you sure it's truly an _empty_ commit message? Can you try git cat-file commit f67f77edf06bbcebabf430735c751245a4b70f14 and look at the result with xxd, hd, or similar.
But the question is then - how did I manage to get my repository in this state? The commit in question was made by me - I know I entered a message when I committed it. I can even find the commit *with* the original commit message in another branch... I am sorry to say that my
It _is_ generally hard to get an empty commit message using "git commit". But it's possible there is a bug in cherry-pick, rebase, or some ohter low-level tool that accidentally erased your message as the commit was moved. -Peff