error: char103: premature end of data

Hi,

I just tried to fetch from one of my repos which was perfectly usable (and 
fetchable) before, and got this error message:

	error: char103: premature end of data

WTF? Since when did we stop using non-cryptic error messages?

Needless to say, I am very unhappy with such a message, especially in a 
repo which worked perfectly, thank you.

I somehow suspect that this has something to do with the recent work on 
the tag objects. If so, NACK on that patch series from me.

Ciao,
Dscho

On Friday 08 June 2007, Johannes Schindelin wrote:

Hi,

I just tried to fetch from one of my repos which was perfectly usable (and 
fetchable) before, and got this error message:

	error: char103: premature end of data

Sorry about that. Do you have an idea of which tag object caused the 
failure? If so, could you send the output of "git-cat-file tag <name>" on 
it?

git-fsck on the repo should report the same error. If you run with -v 
(verbose) you should also get some hints as to which tag object causes 
this.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

Hi,

On Thu, 7 Jun 2007, Johannes Schindelin wrote:

I somehow suspect that this has something to do with the recent work on 
the tag objects. If so, NACK on that patch series from me.

Okay. Instead of doing the work I have to do, which I cannot, because 
a vital part of git stopped working for me, I tracked down that it is 
indeed that monster commit v1.5.2.1-134-gc7de6eb AKA ':/Refactor git tag 
objects;'

I have to repeat my NACK on it. I did not have time to review it, when 
you sent it, so I tried to find what is wrong now (when I don't have 
time for it to begin with).

But it is really intrusive, introduces problems, is less than readable, 
and it is not at all clear what problems it solves, while it looks like it 
could be broken down to easily-reviewable fixes, cleanups, and changes, so 
please fix it while I recover from my troubles.

Ciao,
Dscho

Hi,

On Fri, 8 Jun 2007, Johan Herland wrote:

On Friday 08 June 2007, Johannes Schindelin wrote:

quoted

I just tried to fetch from one of my repos which was perfectly usable 
(and fetchable) before, and got this error message:

	error: char103: premature end of data

Sorry about that. Do you have an idea of which tag object caused the 
failure? If so, could you send the output of "git-cat-file tag <name>" 
on it?

Yes, I know what causes it. A tag with an empty message.

And I even know why it does that. It's easy. Look into git-tag.sh, and you 
will find that it does a git-stripspace on the final message. If that was 
empty, then the tag will just be the tag header.

git-fsck on the repo should report the same error. If you run with -v 
(verbose) you should also get some hints as to which tag object causes 
this.

Yes, it finds the error. And crashes. And costs me time.

Why do we have to parse _everything_ in the tag to begin with? It's not 
like I will show the information of the darn thing when I just fetch it 
from repo A into repo B.

Ciao,
Dscho

On Friday 08 June 2007, Johannes Schindelin wrote:

Hi,

On Fri, 8 Jun 2007, Johan Herland wrote:

quoted

On Friday 08 June 2007, Johannes Schindelin wrote:

quoted

I just tried to fetch from one of my repos which was perfectly usable 
(and fetchable) before, and got this error message:

	error: char103: premature end of data

Sorry about that. Do you have an idea of which tag object caused the 
failure? If so, could you send the output of "git-cat-file tag <name>" 
on it?

Yes, I know what causes it. A tag with an empty message.

Of course. Although if one uses git-tag -a to create an annotated tag object 
I have a hard time seeing why one wouldn't supply a message. But it's of 
course entirly valid not to supply a message.

And I even know why it does that. It's easy. Look into git-tag.sh, and you 
will find that it does a git-stripspace on the final message. If that was 
empty, then the tag will just be the tag header.

You're right. I'll fix my code to handle this case. I'll also try to split
that first patch in my series into more manageable chunks.

quoted

git-fsck on the repo should report the same error. If you run with -v 
(verbose) you should also get some hints as to which tag object causes 
this.

Yes, it finds the error. And crashes. And costs me time.

Why do we have to parse _everything_ in the tag to begin with? It's not 
like I will show the information of the darn thing when I just fetch it 
from repo A into repo B.

We parse the tag completely in order to detect corruption/invalid tags as 
early as possible. If I'm pulling from a corrupt repo, I'd sure as hell 
want git to tell me when I first fetched, and not a couple of weeks later 
when I'd try to use the corrupt data, or call fsck, or whatever.

Again, I'm sorry for your problems.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

Hi,

On Fri, 8 Jun 2007, Johan Herland wrote:

If I'm pulling from a corrupt repo, I'd sure as hell want git to tell me 
when I first fetched, and not a couple of weeks later when I'd try to 
use the corrupt data, or call fsck, or whatever.

We don't check that the object names match the object contents on pull. 
With your argument, we should do that, too. And of course, get rid of 
git-fsck, because it is of no more use, then.

Ciao,
Dscho

Thanks to Johannes Schindelin [off-list ref] for
discovering this.

Also add a testcase for this condition.

Signed-off-by: Johan Herland <redacted>
---

This patch should hopefully fix your problem.


...Johan

 t/t3800-mktag.sh |   15 +++++++++++++++
 tag.c            |    9 ++-------
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/t/t3800-mktag.sh b/t/t3800-mktag.sh
index ac9008a..ac7cbbc 100755
--- a/t/t3800-mktag.sh
+++ b/t/t3800-mktag.sh

@@ -399,5 +399,20 @@ test_expect_success \
     'create valid tag #4' \
     'git-mktag <tag.sig >.git/refs/tags/mytag 2>message'
 
+############################################################
+# 24. create valid tag #4 (with empty message)
+
+cat >tag.sig <<EOF
+object $head
+type commit
+tag mytag
+keywords note
+tagger a
+EOF
+
+test_expect_success \
+    'create valid tag #4' \
+    'git-mktag <tag.sig >.git/refs/tags/mytag 2>message'
+
 
 test_done

diff --git a/tag.c b/tag.c
index e371179..875145b 100644
--- a/tag.c
+++ b/tag.c

@@ -131,10 +131,6 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
 		header_end = memchr(tagger_line, '\n', end - tagger_line);
 		if (!header_end++)
 			return error("char" PD_FMT ": could not find \"\\n\" after \"tagger\"", tagger_line - data);
-		if (end - header_end < 1)
-			return error("char" PD_FMT ": premature end of data", header_end - data);
-		if (*header_end != '\n') /* header must end with "\n\n" */
-			return error("char" PD_FMT ": could not find blank line after header section", header_end - data);
 	}
 	else {
 		/* Treat tagger line as optional */

@@ -148,9 +144,8 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
 			header_end = tagger_line;
 	}
 
-	if (end - header_end < 1)
-		return error("char" PD_FMT ": premature end of data", header_end - data);
-	if (*header_end != '\n') /* header must end with "\n\n" */
+	/* header must end with "\n\n", but "\n" is acceptable if at EOF */
+	if (header_end < end - 1 && *header_end != '\n') /* not at EOF, and next char is not '\n' */
 		return error("char" PD_FMT ": could not find blank line after header section", header_end - data);
 
 	/*

-- 
1.5.2