{"thread":{"id":"7324","subject":"git 1.5.1-rc1 doesn't like empty files","startedAt":"2007-03-20T03:30:24Z","lastAt":"2007-03-20T15:46:21Z","messageCount":18,"participants":["Pavel Roskin","Nicolas Vilz","Linus Torvalds","Junio C Hamano","Shawn O. Pearce","Alexander Litvinov","Andy Parkins"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"37577","messageId":"1174361424.3143.42.camel@dv","threadId":"7324","inReplyTo":null,"subject":"git 1.5.1-rc1 doesn't like empty files","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-03-20T03:30:24Z","receivedAt":"2007-03-20T03:30:24Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI don't know where this problem appeared, but it present in the current\ngit (1.5.1-rc1).  Empty files become invalid objects in the repository:\n\n$ touch file \n$ git-init\nInitialized empty Git repository in .git/\n$ git-add file\n$ git-commit -m \"first commit\"\nCreated initial commit 16a476808d3cb0a4758997ba58193a9dcfad0fd8\nerror: garbage at end of loose object\n'e69de29bb2d1d6434b8b29ae775ad8c2e48c5391'\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 file\n$\n\nA file with a one newline is OK (replace \"touch file with \"echo >file\"\nand the error will go away).\n\nThis is Linux, Fedora Development, i386.\n\nThe testsuite fails at test 7 in t9200-git-cvsexportcommit.sh, but it\nseems to be unrelated.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"37585","messageId":"20070320042438.GA31795@hermes.lan.home.vilz.de","threadId":"7324","inReplyTo":"1174361424.3143.42.camel@dv","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Nicolas Vilz","fromEmail":"niv@iaglans.de","sentAt":"2007-03-20T04:24:38Z","receivedAt":"2007-03-20T04:24:38Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"On Mon, Mar 19, 2007 at 11:30:24PM -0400, Pavel Roskin wrote:\n> Hello!\n> \n> I don't know where this problem appeared, but it present in the current\n> git (1.5.1-rc1).  Empty files become invalid objects in the repository:\n> \n> $ touch file \n> $ git-init\n> Initialized empty Git repository in .git/\n> $ git-add file\n> $ git-commit -m \"first commit\"\n> Created initial commit 16a476808d3cb0a4758997ba58193a9dcfad0fd8\n> error: garbage at end of loose object\n> 'e69de29bb2d1d6434b8b29ae775ad8c2e48c5391'\n>  0 files changed, 0 insertions(+), 0 deletions(-)\n>  create mode 100644 file\n> $\n\nI get the following after the last command:\n\nCreated initial commit a0e02efbe85ee1c1f4b8ba703ccae2f4e64e6ed0\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 file\n\nI use git version 1.5.1.rc1.595.gd1206 on a current gentoo system\n(Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.2,\nglibc-2.5-r1, 2.6.20-gentoo-r3 x86_64)) with a not so current portage \ntree (Timestamp of tree: Sat, 17 Mar 2007 12:00:01 +0000).\n\nin a few hours, i can test that on ppc32 arch, too, if you like.\n\nRegards,\nNicolas Vilz\n"},{"id":"37586","messageId":"Pine.LNX.4.64.0703192148430.6730@woody.linux-foundation.org","threadId":"7324","inReplyTo":"1174361424.3143.42.camel@dv","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-20T04:54:01Z","receivedAt":"2007-03-20T04:54:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Mar 2007, Pavel Roskin wrote:\n> \n> I don't know where this problem appeared, but it present in the current\n> git (1.5.1-rc1).  Empty files become invalid objects in the repository:\n\nHmm.. Not for me. Can you bisect when it started happening?\n\n> This is Linux, Fedora Development, i386.\n\nFC6, tested both i386 and x86-64.\n\nI wonder if this is a zlib issue. Although I seem to have libz-1.2.3 on \nboth machines, and that should be the most recent version. I don't see \nFedora development having anything else..\n\n\t\tLinus\n"},{"id":"37588","messageId":"1174367312.3143.75.camel@dv","threadId":"7324","inReplyTo":"Pine.LNX.4.64.0703192148430.6730@woody.linux-foundation.org","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-03-20T05:08:32Z","receivedAt":"2007-03-20T05:08:32Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-03-19 at 21:54 -0700, Linus Torvalds wrote:\n> \n> On Mon, 19 Mar 2007, Pavel Roskin wrote:\n> > \n> > I don't know where this problem appeared, but it present in the current\n> > git (1.5.1-rc1).  Empty files become invalid objects in the repository:\n> \n> Hmm.. Not for me. Can you bisect when it started happening?\n\nI was doing exactly that, and here's the result:\n\n7efbff7531af4281487d54c1dc1401308d988e33 is first bad commit\ncommit 7efbff7531af4281487d54c1dc1401308d988e33\nAuthor: Junio C Hamano <junkio@cox.net>\nDate:   Mon Mar 5 00:21:37 2007 -0800\n\n    unpack_sha1_file(): detect corrupt loose object files.\n    \n    We did not detect broken loose object files, either when\n    underlying inflate() signalled the breakage, nor inflate()\n    finished and we had garbage trailing at the end.  We do better\n    now.\n    \n    We also make unpack_sha1_file() a static function to\n    sha1_file.c, since it is not used by anybody outside.\n    \n    Signed-off-by: Junio C Hamano <junkio@cox.net>\n\n:100644 100644 c291163e6d2096181ddf89954d2d65953d1ba687 4b5a7541a86c488f623793fdc498d0e149c40439\n M      cache.h\n:100644 100644 6d0a72ed093d353a672129f7e460d0c1015212d7 ac6b5e00b6dec913a39cc54e84829dc3fc6c782f\n M      sha1_file.c\n\n\n.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the same 9\nbytes:  30 78 9c 03 00 00 00 00 01\n\nBut it's considered corrupt by the current git.\n\n> I wonder if this is a zlib issue. Although I seem to have libz-1.2.3 on \n> both machines, and that should be the most recent version. I don't see \n> Fedora development having anything else..\n\nThat's also 1.2.3.  I can reproduce the issue on another machine running\nFedora Core 6 i386 with all updates, also with zlib 1.2.3.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"37589","messageId":"7vslc0bhz7.fsf@assigned-by-dhcp.cox.net","threadId":"7324","inReplyTo":"1174361424.3143.42.camel@dv","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-20T05:29:32Z","receivedAt":"2007-03-20T05:29:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin <proski@gnu.org> writes:\n\n> Hello!\n>\n> I don't know where this problem appeared, but it present in the current\n> git (1.5.1-rc1).  Empty files become invalid objects in the repository:\n>\n> $ touch file \n> $ git-init\n> Initialized empty Git repository in .git/\n> $ git-add file\n> $ git-commit -m \"first commit\"\n> Created initial commit 16a476808d3cb0a4758997ba58193a9dcfad0fd8\n> error: garbage at end of loose object\n> 'e69de29bb2d1d6434b8b29ae775ad8c2e48c5391'\n\nIf the error message above is linewrapped by e-mail, I think it\nis coming from here:\n\n    static void *unpack_sha1_rest(z_stream *stream, void *buffer,...\n    {\n    ...\n            if (bytes < size) {\n                    stream->next_out = buf + bytes;\n                    stream->avail_out = size - bytes;\n                    while (status == Z_OK)\n                            status = inflate(stream, Z_FINISH);\n            }\n            buf[size] = 0;\n            if ((status == Z_OK || status == Z_STREAM_END) && !stream->avail_in) {\n                    inflateEnd(stream);\n                    return buf;\n            }\n\n            if (status < 0)\n                    error(\"corrupt loose object '%s'\", sha1_to_hex(sha1));\n            else if (stream->avail_in)\n                    error(\"garbage at end of loose object '%s'\",\n                          sha1_to_hex(sha1));\n            free(buf);\n            return NULL;\n    }\n\nCan you check what the value of the status is at that point?\n"},{"id":"37592","messageId":"Pine.LNX.4.64.0703192237100.6730@woody.linux-foundation.org","threadId":"7324","inReplyTo":"1174367312.3143.75.camel@dv","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-20T05:41:10Z","receivedAt":"2007-03-20T05:41:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Mar 2007, Pavel Roskin wrote:\n> \n> .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the same 9\n> bytes:  30 78 9c 03 00 00 00 00 01\n\nAhh.. You have\n\n\t[core]\n\t\tlegacyheaders = false\n\ndon't you? If you didn't, you should see a 15-byte object, not a 9-byte \none.\n\nAnd yes, I can reproduce this with that \"core.legacyheaders=false\" \nsetting. It seems that config option is simply broken, and we never \nnoticed, because almost nobody uses it.\n\nAlexander - do you happen to have that \"legacyheaders\" setting too? Maybe \nthat explains your pack corruption?\n\n\t\tLinus\n"},{"id":"37594","messageId":"1174369676.8210.5.camel@dv","threadId":"7324","inReplyTo":"7vslc0bhz7.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-03-20T05:47:56Z","receivedAt":"2007-03-20T05:47:56Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-03-19 at 22:29 -0700, Junio C Hamano wrote:\n>             if (status < 0)\n>                     error(\"corrupt loose object '%s'\",\n> sha1_to_hex(sha1));\n>             else if (stream->avail_in)\n>                     error(\"garbage at end of loose object '%s'\",\n>                           sha1_to_hex(sha1));\n>             free(buf);\n>             return NULL;\n>     }\n> \n> Can you check what the value of the status is at that point?\n\nstatus is 0 (Z_OK), stream->avail_in is 8.  I changed the code to print\nthem from the error() that prints \"garbage at end of loose object\".\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"37595","messageId":"Pine.LNX.4.64.0703192245490.6730@woody.linux-foundation.org","threadId":"7324","inReplyTo":"7vslc0bhz7.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-20T05:49:53Z","receivedAt":"2007-03-20T05:49:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Mar 2007, Junio C Hamano wrote:\n> \n> If the error message above is linewrapped by e-mail, I think it\n> is coming from here:\n\nI think I found it.\n\nThe thing is, if the output buffer is empty, we should *still* actually \nuse the zlib routines to *unpack* that empty output buffer.\n\nBut we had a test that said \"only unpack if we still expect more output\".\n\nSo we wouldn't use up all the zlib stream, because we felt that we didn't \nneed it, because we already had all the bytes we wanted. And it was \n\"true\": we did have all the output data. We just needed to also eat all \nthe input data!\n\nWe've had this bug before - thinking that we don't need to inflate() \nanything because we already had it all..\n\n\t\tLinus\n\n---\n sha1_file.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex b0b2177..c0efed3 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1030,7 +1030,7 @@ static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size\n \t\tn = size;\n \tmemcpy(buf, (char *) buffer + bytes, n);\n \tbytes = n;\n-\tif (bytes < size) {\n+\tif (bytes <= size) {\n \t\tstream->next_out = buf + bytes;\n \t\tstream->avail_out = size - bytes;\n \t\twhile (status == Z_OK)\n"},{"id":"37596","messageId":"1174369838.8210.9.camel@dv","threadId":"7324","inReplyTo":"Pine.LNX.4.64.0703192237100.6730@woody.linux-foundation.org","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-03-20T05:50:38Z","receivedAt":"2007-03-20T05:50:38Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-03-19 at 22:41 -0700, Linus Torvalds wrote:\n> \n> On Tue, 20 Mar 2007, Pavel Roskin wrote:\n> > \n> > .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the same 9\n> > bytes:  30 78 9c 03 00 00 00 00 01\n> \n> Ahh.. You have\n> \n> \t[core]\n> \t\tlegacyheaders = false\n\nYes.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"37597","messageId":"20070320055611.GD29288@spearce.org","threadId":"7324","inReplyTo":"Pine.LNX.4.64.0703192237100.6730@woody.linux-foundation.org","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-20T05:56:11Z","receivedAt":"2007-03-20T05:56:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> On Tue, 20 Mar 2007, Pavel Roskin wrote:\n> > \n> > .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the same 9\n> > bytes:  30 78 9c 03 00 00 00 00 01\n> \n> Ahh.. You have\n> \n> \t[core]\n> \t\tlegacyheaders = false\n> \n> don't you? If you didn't, you should see a 15-byte object, not a 9-byte \n> one.\n> \n> And yes, I can reproduce this with that \"core.legacyheaders=false\" \n> setting. It seems that config option is simply broken, and we never \n> noticed, because almost nobody uses it.\n\nFor what it is worth, I have been running core.legacyheaders=false\non both my PowerBook (my main dev system) and on my x86 Cygwin\nPOS.  I guess I've been lucky, as I've never noticed any sort\nof corruption.\n\nOh, wait, yes I did.  Just the other day.  A loose object got the\nsame zlib error as Pavel asked about.  But git-prune whacked the\ndamn thing.  I figured it was just a short write by Cygwin during\nsome sort of operation that I may have aborted; e.g. aborting an\nupdate-index and running it again later, thus never actually using\nthat particular blob.\n\nI didn't think twice about the error (until now), especially since\n`git-fsck --full` did not whine after the corrupt loose object\nwas gone.\n\n-- \nShawn.\n"},{"id":"37598","messageId":"7v648wbgiy.fsf@assigned-by-dhcp.cox.net","threadId":"7324","inReplyTo":"Pine.LNX.4.64.0703192245490.6730@woody.linux-foundation.org","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-20T06:00:53Z","receivedAt":"2007-03-20T06:00:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> We've had this bug before - thinking that we don't need to inflate() \n> anything because we already had it all..\n>\n> \t\tLinus\n\nThanks.  I think we _do_ need a big fat warning near the code to\navoid the same mistake in the future.  Something like this?\n\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 9fe2bd6..d273aff 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1030,7 +1030,17 @@ static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size\n \t\tn = size;\n \tmemcpy(buf, (char *) buffer + bytes, n);\n \tbytes = n;\n-\tif (bytes < size) {\n+\tif (bytes <= size) {\n+\t\t/*\n+\t\t * The above condition must be (bytes <= size), not\n+\t\t * (bytes < size).  In other words, even if we expect\n+\t\t * no more output, the input zlib stream may have bytes\n+\t\t * that express \"this concludes the stream\", and we do\n+\t\t * want to eat that input.  Otherwise we would not be\n+\t\t * able to test that we consumed all the input to reach\n+\t\t * the expected size *and* zlib gave status == Z_STREAM_END\n+\t\t * to signal all went well.\n+\t\t */\n \t\tstream->next_out = buf + bytes;\n \t\tstream->avail_out = size - bytes;\n \t\twhile (status == Z_OK)\n"},{"id":"37599","messageId":"7v1wjkbgaj.fsf@assigned-by-dhcp.cox.net","threadId":"7324","inReplyTo":"7v648wbgiy.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-20T06:05:56Z","receivedAt":"2007-03-20T06:05:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n>\n>> We've had this bug before - thinking that we don't need to inflate() \n>> anything because we already had it all..\n>>\n>> \t\tLinus\n>\n> Thanks.  I think we _do_ need a big fat warning near the code to\n> avoid the same mistake in the future...\n\nBy the way, I think the test that comes after the part you fixed\nis wrong (I know it is my bad without running git-blame).  Since\nwe are making sure that we eat everything, we should expect\nZ_STREAM_END and no avail_in.\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex d7dc80d..7dc16ea 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1037,7 +1037,7 @@ static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size\n \t\t\tstatus = inflate(stream, Z_FINISH);\n \t}\n \tbuf[size] = 0;\n-\tif ((status == Z_OK || status == Z_STREAM_END) && !stream->avail_in) {\n+\tif (status == Z_STREAM_END && !stream->avail_in) {\n \t\tinflateEnd(stream);\n \t\treturn buf;\n \t}\n"},{"id":"37603","messageId":"200703201304.05902.litvinov2004@gmail.com","threadId":"7324","inReplyTo":"Pine.LNX.4.64.0703192237100.6730@woody.linux-foundation.org","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2007-03-20T07:04:05Z","receivedAt":"2007-03-20T07:04:05Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"В сообщении от Tuesday 20 March 2007 11:41 Linus Torvalds написал:\n> Alexander - do you happen to have that \"legacyheaders\" setting too? Maybe\n> that explains your pack corruption?\n\nIt seems no:\n\n$  git config core.legacyheaders\n$  git config -l\nuser.name=Alexander Litvinov\nuser.email=XXX\ncore.logallrefupdates=true\ncore.filemode=false\ncore.autocrlf=true\ndiff.color=auto\nstatus.color=auto\napply.whitespace=strip\ncore.repositoryformatversion=0\ncore.filemode=false\ncore.bare=false\nremote.origin.url=/home/lan/src/XXX\nremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\nbranch.master.remote=origin\nbranch.master.merge=refs/heads/master\nbranch.XXX.remote=origin\nbranch.XXX.merge=refs/heads/XXX\n"},{"id":"37608","messageId":"200703200843.51473.andyparkins@gmail.com","threadId":"7324","inReplyTo":"Pine.LNX.4.64.0703192237100.6730@woody.linux-foundation.org","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-20T08:43:50Z","receivedAt":"2007-03-20T08:43:50Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 March 20 05:41, Linus Torvalds wrote:\n\n> \t[core]\n> \t\tlegacyheaders = false\n> noticed, because almost nobody uses it.\n\nI'm not sure that's going to be true for long - the 1.5.0 release notes \nrecommended setting it (assuming you didn't need backward compatibility) - \nwhich is exactly what I (and I'm sure others) did.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37609","messageId":"7vbqio7100.fsf@assigned-by-dhcp.cox.net","threadId":"7324","inReplyTo":"200703200843.51473.andyparkins@gmail.com","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-20T08:49:51Z","receivedAt":"2007-03-20T08:49:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Tuesday 2007 March 20 05:41, Linus Torvalds wrote:\n>\n>> \t[core]\n>> \t\tlegacyheaders = false\n>> noticed, because almost nobody uses it.\n>\n> I'm not sure that's going to be true for long - the 1.5.0 release notes \n> recommended setting it (assuming you didn't need backward compatibility) - \n> which is exactly what I (and I'm sure others) did.\n\nWell, it is fixed in 'master' to be in -rc2, and that validation\ndoes not exist in 'maint', so no harm is done.\n"},{"id":"37611","messageId":"200703200926.05176.andyparkins@gmail.com","threadId":"7324","inReplyTo":"7vbqio7100.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-20T09:26:00Z","receivedAt":"2007-03-20T09:26:00Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 March 20 08:49, Junio C Hamano wrote:\n\n> >> noticed, because almost nobody uses it.\n> >\n> > I'm not sure that's going to be true for long - the 1.5.0 release notes\n> > recommended setting it (assuming you didn't need backward compatibility)\n> > - which is exactly what I (and I'm sure others) did.\n>\n> Well, it is fixed in 'master' to be in -rc2, and that validation\n> does not exist in 'maint', so no harm is done.\n\nIt wasn't the presence of the bug I was highlighting - it was the idea that \nnobody uses that option.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37628","messageId":"Pine.LNX.4.64.0703200843270.6730@woody.linux-foundation.org","threadId":"7324","inReplyTo":"200703200926.05176.andyparkins@gmail.com","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-20T15:45:21Z","receivedAt":"2007-03-20T15:45:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Mar 2007, Andy Parkins wrote:\n\n> On Tuesday 2007 March 20 08:49, Junio C Hamano wrote:\n> \n> > >> noticed, because almost nobody uses it.\n> > >\n> > > I'm not sure that's going to be true for long - the 1.5.0 release notes\n> > > recommended setting it (assuming you didn't need backward compatibility)\n> > > - which is exactly what I (and I'm sure others) did.\n> >\n> > Well, it is fixed in 'master' to be in -rc2, and that validation\n> > does not exist in 'maint', so no harm is done.\n> \n> It wasn't the presence of the bug I was highlighting - it was the idea that \n> nobody uses that option.\n\nYeah, I'm actually happy that people seem to be using it, and it looks \nlike the bug really was totally harmless apart from triggering a bogus \nerror (ie it would never have corrupted anything, it just triggered an \nerror that it shouldn't have).\n\nAnd I think the only thing that could ever trigger it was really that \nspecial case of a zero-sized blob (or maybe an empty tree, but git doesn't \ngenerate those natively unless you do magic stuff by hand).\n\n\t\tLinus\n"},{"id":"37629","messageId":"Pine.LNX.4.64.0703200846110.6730@woody.linux-foundation.org","threadId":"7324","inReplyTo":"7v1wjkbgaj.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 1.5.1-rc1 doesn't like empty files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-20T15:46:21Z","receivedAt":"2007-03-20T15:46:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Mar 2007, Junio C Hamano wrote:\n> \n> By the way, I think the test that comes after the part you fixed\n> is wrong (I know it is my bad without running git-blame).  Since\n> we are making sure that we eat everything, we should expect\n> Z_STREAM_END and no avail_in.\n\nAck.\n\n\t\tLinus\n"}]}