Re: [bug in next ?] git-fetch/git-push issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 05, 2007 at 06:46:08PM -0500, Daniel Barkalow wrote:

> -	if (!args.dry_run && remote && ret == 0) {
> +	if (!args.dry_run && remote && ret != -4) {
>  		for (ref = remote_refs; ref; ref = ref->next)
>  			update_tracking_ref(remote, ref);
>  	}
> 
> That is, -2 means that we've done less than was asked, but nothing blew 
> up; -4 means something blew up. When we skip something, we drop peer_ref 
> from it, so there's nothing to update (and it's dropped from the set of 
> mappings, in case we cared further about it with respect to reporting the 
> actions we actually took). Then we update all refs that were acted on if 
> ret isn't -4, and we return non-zero if ret is either -2 or -4.

This is OK, I guess. But it really doesn't accomplish the useful thing
we might get by noting per-ref errors, which is that we _can_ update the
tracking refs for those refs where it is appropriate.

We would have to parse the lines from receive_status and match them with
refs. I started a patch to do this, but I wonder if it is really worth
it. I would think that 99% of the time you have a failure at the sending
level, it's because the connection is broken, and you have no idea
_which_ refs were updated anyway, and you have to assume that none were.
So perhaps it is OK to just treat the two classes of errors differently,
and only cover per-ref errors for the "-2" case.

-Peff
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux