Junio C Hamano <gits...@pobox.com> writes: > Sitaram Chamarty <sitar...@gmail.com> writes: > >> Uggh, no. Client-git should only talk to server-git. It shouldn't be >> talking first to some *other* program (in this case gitolite), and >> then to to server-git. That doesn't sound sane to me. >> >> You should wrap this whole thing around something else that does it in >> 3 steps. Check, create if needed, then the actual git command you >> intend to run. All this should be local to your environment, not >> rolled into git; it's far too specific to be rolled into git itself, >> if you ask me. > > Thanks for saving me from having to state an obvious sanity ;-)
Having said all that, I am not fundamentally opposed to new features added to the git protocol. The responses so far from me in this thread were primarily me reacting to (1) auto creation by gitolite is a bad example and (2) the proposal sounded, at least to me, that it wants to add random and uncontrolled interactions between the sides outside the defined protocol exchange (e.g. "pusher connects, pushee says what it has and what capabilities it supports, pusher says what it wants to update how and chooses what capabilities it wants to use in the exchange, sends the pack data, ..."), which is an unworkable idea. For people who do not understand how the git protocol works (the proposal that started this thread included), a bit of clarification on (2) may help. Long time ago, we did not have "report-status" capability (think of a "capability" as a "protocol extension"). The "git push" protocol exchange ended with the pusher sending the pack data and that was the end of conversation. But we realized that it would be beneficial for the pushee to be able to tell the pusher that the push failed at the protocol level, so that the "git push" program can exit with an error code. The version of the "git push" program that was current at the time exited with success unconditionally, as long as all protocol exchange went well and all the pack data was sent successfully. The program's flow was not expecting any response once the pack data started flowing from it to the pushee, so that is the only reasonable behaviour. So what did we do? We added "report-status" capability to the capability suite, and made new versions of "receive-pack" program advertise it. Existing versions of "git push" did not know about this capability, so they did not ask for it and pusher and pushee worked exactly as before. But that way, the new versions of "git push" can learn to ask for "report-status" capability to updated "receive-pack", and the new versions of "receive-pack", after receiving and processing the pack data stream, can send new messages the original protocol did not allow it to send to "git push". An important point to understand is that there is one more thing that is needed. The updated "git push" that asks for "report-status" needed to learn how to interpret the new message and act on it. Another example in the same protocol was the addition of "sideband" capability. Before that happened, there was no way to send the error stream from the pushee to the pusher. Unlike "report-status" that happens at the very end, this actually changes the way how the remainder of the protocol exchange proceeds once it is activated. You could add a new capability that says "when in effect, both ends can write to and read from new sidebands 4 and 5 to communicate out of line", but that is not all that useful. You need to make the updated programs to agree on what should happen to the main interaction when a new kind of communication is made out of band. For example, you may ask "do you really mean it [Y/n]?" to the client, pause the entire transaction until you hear Yes or No from the client, and you may even choose to do something different from the usual when the client says No, but you also need to update the client to behave differently after that, perhaps by defining a new conversation path in the protocol. At that point, you would need to handle real and concrete definition of the extended protocol and the code on the both sides to support it _anyway_. For example, imagine that you want to let a new user interaction to verify the repository it is pushing to. How would we do that with your "adding random interaction between the server and client"? The server end notices that the user is trying to push into one repository. throws "Do you really mean to push into repository foo?" Updated client that understands your "random interaction" extention is capable of show this message, pauses until the user says "Yes" or "No", and sends it back to the server end. If the answer is "No", the client may want to say "No, the repository I really wanted to push into was not foo, but bar". How did the client _know_ the "Do you really mean" message from the server requires a Yes or No response in the above scenario? How did the client know, when saying "No", to ask the real URL of the repository to the end user, disconnect the current session with the server, and restart itself using the real URL of the repository? All of that need clearly defined new protocol exchange steps, state transitions, and new conditional and new codepaths to implement them. It cannot be just "let's allow the server and the client to randomly exchange packets out of band". In short, I am not fundamentally opposed to protocol extension, as I said in my very first response. I however do not think allowing the server 'to communicate directly to the git user' (which was the phrase used in the original message that expressed the idea) is a good idea, at least for two reasons: - because we already have a proven-to-work-well way to extend the protocol via "capability"; and - because doing so is not useful for the purpose of extending the feature of the protocol, -- 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
