After looking at $gmane/264000 again, maybe the client should talk first stating all the relevant information it wants to get, though I realize this is not part of capabilities so maybe it could even before, such as:
Client: All I want to do is an ls-remote, so only Phase 2, no transmission of blobs phase 3 Server: ok Client[as in the previous mail]: Last time we talked you advertised hashed to $SHA Server: that's correct! As the server knows the client doesn't want to know about Phase3, it can omit things relevant to that phase such as the signed push nonce. So from a high level perspective we'd maybe need 4 phases like Phase 0) declare the intent (fetch/push all or partial parts) Phase 1) negotiation of capabilities Phase 2) ref advertisement (i.e. changes in the DAG end points) Phase 3) transmitting the missing blobs. The problem may be that phase 0 and 1 may require mixing, as you may want to declare new things to do in 0) which you would have needed to advertise as a capability in 1). So maybe we need to swap that around: Phase 1a) negotiation of capabilities Phase 1b) negotiation of intent (fetch/push of all/few branches in full/shallow/narrow fashion) Phase 2) ref advertisement (i.e. changes in the DAG end points) Phase 3) transmitting the missing blobs. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html