Sitaram Chamarty <sitar...@gmail.com> writes:
> As I may have said earlier, this interaction is far too site-specific
> to be rolled into git itself.
> How about a new hook instead? A pre-pack-protocol hook that acts as
> if it was called by the remote user as a command, and if it exit's
> with 0, then the real pack protocol starts else it gets aborted. Let
> him do whatever he wants in there. Arguments to the hook will be repo
> name and command (git-upload-pack mainly).
Not very interested. If it is _known_ to happen before Git protocol
proper happens, why not give the user something like the gitolite
command "D", that is interpreted by gitolite-shell without bothering
Git at all?
After all, at least you and I share the understanding that once the
conversation in Git protocol proper starts, there is no place for
such a random hook to affect further behaviour of the protocol, so
the approach "hook" can only solve narrow "before gitolite-shell (or
git-shell or whatever-shell) decides it is time to call Git" cases,
and the only way it can affect the outcome of the main conversation
is to abort it without graceful degradation, or let the main
conversation continue as if nothing happened. I think we agree
between us that "a new hook", while it may be _a_ way to do
something new, is _not_ a good way to do so. Why add such a wart?
> And even then, all we are doing is rolling into git something that he
> can very easily do outside right now on his own environment ...
Yes, that is a repeat of what you told him already, to which I said
"thanks for sanity", I think ;-).
I am not opposed to protocol enhancements, but a new feature that
has to change what either end does should be added properly at the
protocol level as a protocol capability, not added out of band with
band-aid, leaving the main conversation oblivious to what is going
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