Johan Herland <johan@xxxxxxxxxxx> writes:
> Therefore, we should try to read from the remote end, even when pack-objects
> dies unexepectedly. We accomplish this by _always_ calling receive_status()
> after pack_objects(). If the remote end managed to produce a well-formed
> status report before exiting, then receive_status() simply presents that to
> the user. Even if the data from the remote end cannot be understood by
> receive_status(), it will print that data as part of its error message. In
> any case, we give the user as much information about the failure as possible.
> diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> index c1f6ddd..5ba5262 100644
> --- a/builtin/send-pack.c
> +++ b/builtin/send-pack.c
> @@ -251,7 +251,7 @@ int send_pack(struct send_pack_args *args,
> int status_report = 0;
> int use_sideband = 0;
> unsigned cmds_sent = 0;
> - int ret;
> + int ret = 0;
> struct async demux;
>
> /* Does the other end support the reporting? */
> @@ -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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html