On Thu, Dec 24, 2009 at 03:44:45PM +0800, Tay Ray Chuan wrote:
> - ref->status = status;
> - ref->remote_status = msg;
> + switch (ref->status) {
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + case REF_STATUS_UPTODATE:
> + /*
> + * Earlier, the ref was marked not to be pushed, so ignore what
> + * the remote helper said about the ref.
> + */
> + continue;
> + default:
> + ref->status = status;
> + ref->remote_status = msg;
> + }
It seems like this should be checking for REF_STATUS_NONE explicitly
instead of trying to enumerate the reasons we might not have tried to
push. Shouldn't helpers _only_ be pushing REF_STATUS_NONE refs?
I think right now the two cases are equivalent, since non-ff and
uptodate are the only two states set before the helper is invoked. But
we have discussed in the past (and I still have a patch floating around
for) a REF_STATUS_REWIND which would treat strict rewinds differently
(silently ignoring them instead of making an error). Explicitly checking
REF_STATUS_NONE future-proofs against new states being added.
-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