{"thread":{"id":"6839","subject":"[PATCH] pretend-sha1: grave bugfix.","startedAt":"2007-02-16T01:16:18Z","lastAt":"2007-02-16T07:29:39Z","messageCount":4,"participants":["Junio C Hamano","Johannes Schindelin","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"34755","messageId":"7v3b56dhr1.fsf@assigned-by-dhcp.cox.net","threadId":"6839","inReplyTo":null,"subject":"[PATCH] pretend-sha1: grave bugfix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-16T01:16:18Z","receivedAt":"2007-02-16T01:16:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We stashed away objects that we pretend to have, but did not save the\nactual data.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n * I wonder how recent merge-recursive with multiple merge bases\n   (or an empty one) ever worked with this bug.  Am I\n   hallucinating?\n\n sha1_file.c |    4 +++-\n 1 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex b83f59f..2c87031 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1545,11 +1545,13 @@ int pretend_sha1_file(void *buf, unsigned long len, const char *type, unsigned c\n \tco = &cached_objects[cached_object_nr++];\n \tco->size = len;\n \tco->type = strdup(type);\n+\tco->buf = xmalloc(len);\n+\tmemcpy(co->buf, buf, len);\n \thashcpy(co->sha1, sha1);\n \treturn 0;\n }\n \n-void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size)\n+void *read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size)\n {\n \tunsigned long mapsize;\n \tvoid *map, *buf;\n-- \n1.5.0.31.g78e90\n"},{"id":"34764","messageId":"Pine.LNX.4.63.0702160503290.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6839","inReplyTo":"7v3b56dhr1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] pretend-sha1: grave bugfix.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-16T04:05:01Z","receivedAt":"2007-02-16T04:05:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Feb 2007, Junio C Hamano wrote:\n\n>  * I wonder how recent merge-recursive with multiple merge bases\n>    (or an empty one) ever worked with this bug.  Am I\n>    hallucinating?\n\nProbably the fact helped that merge-recursive only pretends \nzero-sized blobs.\n\nCiao,\nDscho\n"},{"id":"34769","messageId":"20070216050943.GD28894@spearce.org","threadId":"6839","inReplyTo":"Pine.LNX.4.63.0702160503290.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] pretend-sha1: grave bugfix.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-16T05:09:43Z","receivedAt":"2007-02-16T05:09:43Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Thu, 15 Feb 2007, Junio C Hamano wrote:\n> \n> >  * I wonder how recent merge-recursive with multiple merge bases\n> >    (or an empty one) ever worked with this bug.  Am I\n> >    hallucinating?\n> \n> Probably the fact helped that merge-recursive only pretends \n> zero-sized blobs.\n\nMost definately.  We never look at the pointer to an object's data if\nlen == 0, which it does in this case of merge-recursive's empty tree.\n\nAren't we using this for git-blame --contents?  How'd that ever\nwork for a non-empty file?\n\n-- \nShawn.\n"},{"id":"34777","messageId":"7v8xeya7bw.fsf@assigned-by-dhcp.cox.net","threadId":"6839","inReplyTo":"20070216050943.GD28894@spearce.org","subject":"Re: [PATCH] pretend-sha1: grave bugfix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-16T07:29:39Z","receivedAt":"2007-02-16T07:29:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Aren't we using this for git-blame --contents?  How'd that ever\n> work for a non-empty file?\n\nMy guess is that git-blame's blob handling has its own built-in\ncache to avoid read_sha1_file(), and that single \"initial\" blob\nis primed by hand, so read_sha1_file() is usually not called for\nthat object name.\n"}]}