On Mon, 5 Nov 2007, Junio C Hamano wrote:

quoted text
> Jeff King <peff@peff.net> writes:
> 
> > Which I guess is what you were trying to accomplish by removing the
> > peer_ref, though I think that doesn't distinguish between "didn't match
> > a remote ref" and "had an error." Perhaps we just need an error flag in
> > the ref struct?
> 
> I agree that makes the most sense.
> 
> As Steffen has been advocating on another thread, depending on
> your workflow, you do not care about some classes of push errors
> per pushed refs.  The update of the remote and local tracking
> refs should be done in sync (i.e. if the remote wasn't updated,
> never update the corresponding local), but it can depend on the
> nature of the failure if a failure to update a remote ref should
> result in the non-zero exit status from git-push as a whole.
> 
> And to implement that, per-ref error flag would be a good way to
> go, methinks.

I think dropping peer_ref may be the clearest semantics. If push decides 
not to actually perform a push, we can just remove it from the list of 
operations we're performing. Independant of this, we can decide whether to 
signal an error, and whether an error means that the remote end will have 
done nothing at all (in which case, we must not update tracking refs).

That is, on top of my changes in other email, Steffan would have the 
strictly behind case just not have the "ret = -2" and everything else 
would be fine.

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html