On Tue, Feb 10, 2009 at 12:15:54PM +0100, Tor Arvid Lund wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
