On Mon, 5 Nov 2007, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
