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

Re: Enhancements to git-protocoll

From
Sitaram Chamarty <sitaramc@gmail.com>
Date
Jul 29, 2012, 15:15 UTC
Message-ID
<CAMK1S_hHBB9BViH=CFuJNgMJzMtzhE0mGc7ryFaDWNxOoH2Pgg@mail.gmail.com>
In-Reply-To
<20120729150550.GA17679@paksenarrion.iveqy.com>
On Sun, Jul 29, 2012 at 8:35 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
Show 27 quoted lines
> On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote:
>> > Thanks, however I think auto-creation is a great feature for some cases
>> > and I think there can be even more useable functions if we could get
>> > user interaction.
>>
>> For the record, I don't think I agree.  There's a place to create a
>> human-conversation, and there's a place not to.
>>
>> If you want a dialog with the server, there should be *other* commands
>> that do that, instead of overloading git's own protocol.
>>
>> Since you mentioned gitolite, consider copying the fork command
>> (src/commands/fork) and munging the code into an explicit wild repo
>> create.
>
> I appriciate that you clearified you oppinion. Please excuse me if it
> sounded as I in any way speaked for gitolite. I use gitolite as an
> example becuase the target application in this case is unknown to most
> people (think gitolite with db-backend for user permissions).
>
> It's a valid design oppinion to not mix git protocoll with anything
> else. But gitolite already does that. Gitolite already have user
> interaction mixed with git interaction. Do you say to me that gitolite
> is broken and should not do user interaction over git-commands? Then why
> does wild repos exists and why does gitolite error messages exists?
>
> We're already down that road, why not do it better?

I think you misunderstood how gitolite works. Gitolite does not have *any* user interaction other than sending some extra messages back via STDERR if you're using a normal git client to do normal git operations (clone/fetch/ls-remote).

Such messages are *no different* from something that an update or pre-receive hook might send back even on a normal (no gitolite) git server.

The only time that gitolite might have any user *interaction* is when using "gitolite commands". These do not run git at all (neither on the client nor on the server), and in fact merely provide a convenient way to allow users to run a controlled set of specific *shell* commands.

Previous: Fredrik GustafssonNext: Fredrik Gustafsson
Message 23 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.