git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Enhancements to git-protocoll

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 30, 2012, 01:28 UTC
Message-ID
<7vr4rut4u9.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CAMK1S_geKq5DkNAy2wxGt5EmoOesxaSKKuQjVaQVcbRVdR+9gA@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
Show 8 quoted lines
> 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 on ouside.

Previous: Sitaram ChamartyNext: Sitaram Chamarty
Message 17 of 25 in “Enhancements to git-protocoll”
  1. Fredrik GustafssonJul 28, 2012
  2. Junio C HamanoJul 29, 2012
  3. Fredrik GustafssonJul 29, 2012
  4. Sitaram ChamartyJul 29, 2012
  5. Junio C HamanoJul 29, 2012
  6. Fredrik GustafssonJul 29, 2012
  7. Sitaram ChamartyJul 30, 2012
  8. Junio C HamanoJul 29, 2012
  9. Sitaram ChamartyJul 30, 2012
  10. Shawn PearceJul 30, 2012
  11. Sitaram ChamartyJul 30, 2012
  12. Junio C HamanoJul 30, 2012
  13. Shawn PearceJul 30, 2012
  14. Junio C HamanoJul 30, 2012
  15. Sitaram ChamartyJul 30, 2012
  16. Sitaram ChamartyJul 30, 2012
  17. Junio C HamanoJul 30, 2012
  18. Sitaram ChamartyJul 30, 2012
  19. Sitaram ChamartyJul 29, 2012
  20. Fredrik GustafssonJul 29, 2012
  21. Sitaram ChamartyJul 29, 2012
  22. Fredrik GustafssonJul 29, 2012
  23. Sitaram ChamartyJul 29, 2012
  24. Fredrik GustafssonJul 29, 2012
  25. Sitaram ChamartyJul 29, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.