From: Johan Herland <johan@herland.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Shawn Pearce <spearce@spearce.org>
Subject: Re: [PATCHv4 02/10] send-pack: Attempt to retrieve remote status even if pack-objects fails
Date: Tue, 24 May 2011 00:58:10 +0200 [thread overview]
Message-ID: <201105240058.10974.johan@herland.net> (raw)
In-Reply-To: <7vei3puqp2.fsf@alter.siamese.dyndns.org>
On Monday 23 May 2011, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > @@ -339,25 +339,18 @@ int send_pack(struct send_pack_args *args,
> >
> > }
> >
> > if (new_refs && cmds_sent) {
> >
> > - if (pack_objects(out, remote_refs, extra_have, args) < 0) {
> > - for (ref = remote_refs; ref; ref = ref->next)
> > - ref->status = REF_STATUS_NONE;
> > + if ((ret = pack_objects(out, remote_refs, extra_have, args))) {
>
> I am not very familiar with this codepath, but you no longer set
> ref->status to REF_STATUS_NONE ...
>
> > ...
> >
> > if (status_report && cmds_sent)
> >
> > - ret = receive_status(in, remote_refs);
> > - else
> > - ret = 0;
> > + ret |= receive_status(in, remote_refs);
>
> ... before calling receive_status() here, and that function can return
> early without setting anything.
>
> Would that have any negative effect on the code that comes after this
> part in the codepath? or if receive_status() returns a failure, we do
> not even look at ref->status?
Hmm... I believe I proved the correctness of this to myself when I first
wrote the patch, but looking at it a second time, I see that I only did so
for send_pack() itself. The remote_refs (that no longer has each ref->status
set to REF_STATUS_NONE on pack_objects() failure) are given as an argument
to send_pack(), and are still used by the caller after send_pack() has
returned (even when it returns with errors).
Therefore, I was wrong to remove this "ref->status = REF_STATUS_NONE" loop.
Will be fixed in the next iteration.
Thanks for noticing,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2011-05-23 22:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 0:51 [PATCHv4 00/10] Push limits Johan Herland
2011-05-23 0:51 ` [PATCHv4 01/10] Update technical docs to reflect side-band-64k capability in receive-pack Johan Herland
2011-05-23 0:51 ` [PATCHv4 02/10] send-pack: Attempt to retrieve remote status even if pack-objects fails Johan Herland
2011-05-23 20:06 ` Junio C Hamano
2011-05-23 22:58 ` Johan Herland [this message]
2011-05-23 0:51 ` [PATCHv4 03/10] Tighten rules for matching server capabilities in server_supports() Johan Herland
2011-05-23 0:51 ` [PATCHv4 04/10] receive-pack: Prepare for addition of the new 'limit-*' family of capabilities Johan Herland
2011-05-23 20:21 ` Junio C Hamano
2011-05-24 0:16 ` Johan Herland
2011-05-23 0:51 ` [PATCHv4 05/10] pack-objects: Teach new option --max-commit-count, limiting #commits in pack Johan Herland
2011-05-23 23:17 ` Junio C Hamano
2011-05-24 0:18 ` Johan Herland
2011-05-23 0:51 ` [PATCHv4 06/10] send-pack/receive-pack: Allow server to refuse pushes with too many commits Johan Herland
2011-05-23 23:39 ` Junio C Hamano
2011-05-24 1:11 ` Johan Herland
2011-05-23 0:52 ` [PATCHv4 07/10] pack-objects: Allow --max-pack-size to be used together with --stdout Johan Herland
2011-05-24 0:09 ` Junio C Hamano
2011-05-24 1:15 ` Johan Herland
2011-05-23 0:52 ` [PATCHv4 08/10] send-pack/receive-pack: Allow server to refuse pushing too large packs Johan Herland
2011-05-24 0:12 ` Junio C Hamano
2011-05-23 0:52 ` [PATCHv4 09/10] pack-objects: Estimate pack size; abort early if pack size limit is exceeded Johan Herland
2011-05-23 16:11 ` Shawn Pearce
2011-05-23 17:07 ` Johan Herland
2011-05-24 0:18 ` Junio C Hamano
2011-05-24 1:17 ` Johan Herland
2011-05-23 0:52 ` [PATCHv4 10/10] receive-pack: Allow server to refuse pushes with too many objects Johan Herland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105240058.10974.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).