From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: fetch_refs_via_pack() discards status? Date: Wed, 05 Dec 2007 13:06:25 -0800 Message-ID: <7vwsrsonqm.fsf@gitster.siamese.dyndns.org> References: <20071122160959.GA3411@steel.home> <7v3aunqvha.fsf_-_@gitster.siamese.dyndns.org> <7vk5nt1v7k.fsf@gitster.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Shawn O. Pearce" , Git Mailing List To: Daniel Barkalow X-From: git-owner@vger.kernel.org Wed Dec 05 22:07:08 2007 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1J01SJ-0002em-Lt for gcvg-git-2@gmane.org; Wed, 05 Dec 2007 22:06:56 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751754AbXLEVGe (ORCPT ); Wed, 5 Dec 2007 16:06:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751799AbXLEVGe (ORCPT ); Wed, 5 Dec 2007 16:06:34 -0500 Received: from sceptre.pobox.com ([207.106.133.20]:49784 "EHLO sceptre.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751749AbXLEVGd (ORCPT ); Wed, 5 Dec 2007 16:06:33 -0500 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 39A192EF; Wed, 5 Dec 2007 16:06:53 -0500 (EST) Received: from pobox.com (ip68-225-240-77.oc.oc.cox.net [68.225.240.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id AF1D59D490; Wed, 5 Dec 2007 16:06:48 -0500 (EST) In-Reply-To: (Daniel Barkalow's message of "Wed, 5 Dec 2007 14:16:04 -0500 (EST)") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Daniel Barkalow writes: > On Tue, 4 Dec 2007, Junio C Hamano wrote: > >> The code calls fetch_pack() to get the list of refs it fetched, and >> discards refs and always returns 0 to signal success. >> >> But builtin-fetch-pack.c::fetch_pack() has error cases. The function >> returns NULL if error is detected (shallow-support side seems to choose >> to die but I suspect that is easily fixable to error out as well). >> >> Shouldn't fetch_refs_via_pack() propagate that error to the caller? > > I think that's right. I think I got as far as having the error status from > fetch_pack() actually returned correctly, and then failed to look at it. > I'd personally avoid testing a pointer to freed memory, but that's > obviously not actually wrong. > > -Daniel Hmph, is that an Ack that the patchlet is actually a bugfix?