On Fri, Feb 05, 2010 at 03:05:24PM -0500, Larry D'Anna wrote: > > So shouldn't it just be: > > > > if (args->porcelain && args->dry_run) > > return 0; > > > > after we check for transport errors but before the loop that you are > > modifying. > > I don't know what the deal is with REF_STATUS_EXPECTING_REPORT, so I > didn't want to modify the behavior in the case that ref->status was > that. What does expecting report mean? It means we told the other side we wanted to push that ref, and we expect it to give us a status report. Most refs are in that state for a short period, and then moved to their final state in builtin-send-pack.c:receive_status. But if we never get a status for that ref for some reason, then that could be the final state. But more to the point, I don't think this bit of code should _have_ to care what it means. If there is a per-ref error with "push --dry-run --porcelain", it will be shown on that ref's output line. So I think your proposal should simply be "if dry-run and porcelain, don't bother looking at per-ref errors at all". You don't care what the per-ref error is; they are all in the same class from the perspective of this change. -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