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

Re: [WIP 11/15] serve: introduce git-serve

From
BWBrandon Williams <bmwill@google.com>
Date
Dec 8, 2017, 20:25 UTC
Message-ID
<20171208202530.GE140529@google.com>
In-Reply-To
<xmqq8teeaywm.fsf@gitster.mtv.corp.google.com>
On 12/07, Junio C Hamano wrote:
Show 32 quoted lines
> Brandon Williams <bmwill@google.com> writes:
> 
> > +static struct protocol_capability *get_capability(const char *key)
> > +{
> > +	int i;
> > +
> > +	if (!key)
> > +		return NULL;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(capabilities); i++) {
> > +		struct protocol_capability *c = &capabilities[i];
> > +		const char *out;
> > +		if (skip_prefix(key, c->name, &out) && (!*out || *out == '='))
> > +			return c;
> 
> Looks familiar and resembles what was recently discussed on list ;-)
> 
> > +int cmd_serve(int argc, const char **argv, const char *prefix)
> > +{
> > +
> > +	struct option options[] = {
> > +		OPT_END()
> > +	};
> > +
> > +	/* ignore all unknown cmdline switches for now */
> > +	argc = parse_options(argc, argv, prefix, options, grep_usage,
> > +			     PARSE_OPT_KEEP_DASHDASH |
> > +			     PARSE_OPT_KEEP_UNKNOWN);
> > +	serve();
> > +
> > +	return 0;
> > +}

I assume that at some point we may want to have a new endpoint that just does v2 without needing the side channel to tell it to do so. Maybe for brand new server commands, like a remote grep or a remote object-stat or something that don't have a v1 equivalent that can be fallen back to. That's why I included a builtin/serve.c

Show 20 quoted lines
> > ...
> > +/* Main serve loop for protocol version 2 */
> > +void serve(void)
> > +{
> > +	/* serve by default supports v2 */
> > +	packet_write_fmt(1, "version 2\n");
> > +
> > +	advertise_capabilities();
> > +
> > +	for (;;)
> > +		if (process_request())
> > +			break;
> > +}
> 
> I am guessing that this would be run just like upload-pack,
> i.e. invoked via ssh or via git-daemon, and that is why it can just
> assume that fd#0/fd#1 are already connected to the other end.  It
> may be helpful to document somewhere how we envision to invoke this
> program.
> 

This function I was planning to just be executed by upload-pack and receive-pack when a client requests protocol v2. But yes the idea would be that fd#0/fd#1 would be already setup like they are for upload-pack and receive-pack.

-- 
Brandon Williams
Previous: Junio C HamanoNext: Brandon Williams
Message 41 of 47 in “[RFC] protocol version 2”
  1. Brandon WilliamsOct 20, 2017
  2. Junio C HamanoOct 24, 2017
  3. Brandon WilliamsOct 24, 2017
  4. Junio C HamanoOct 25, 2017
  5. Junio C HamanoOct 26, 2017
  6. Derrick StoleeOct 25, 2017
  7. Brandon WilliamsOct 25, 2017
  8. Philip OakleyOct 28, 2017
  9. Brandon WilliamsOct 31, 2017
  10. Jonathan TanNov 10, 2017
  11. 00/15 protocol version 2Brandon Williams, Dec 4, 2017
  12. 01/15 pkt-line: introduce packet_read_with_statusBrandon Williams, Dec 4, 2017
  13. Stefan BellerDec 7, 2017
  14. Brandon WilliamsDec 8, 2017
  15. 02/15 pkt-line: introduce struct packet_readerBrandon Williams, Dec 4, 2017
  16. Stefan BellerDec 7, 2017
  17. Brandon WilliamsDec 8, 2017
  18. 03/15 pkt-line: add delim packet supportBrandon Williams, Dec 4, 2017
  19. Stefan BellerDec 7, 2017
  20. Brandon WilliamsDec 8, 2017
  21. 04/15 upload-pack: convert to a builtinBrandon Williams, Dec 4, 2017
  22. Junio C HamanoDec 6, 2017
  23. Johannes SchindelinDec 7, 2017
  24. Junio C HamanoDec 8, 2017
  25. Brandon WilliamsDec 8, 2017
  26. 07/15 connect: convert get_remote_heads to use struct packet_readerBrandon Williams, Dec 4, 2017
  27. Junio C HamanoDec 6, 2017
  28. Brandon WilliamsDec 8, 2017
  29. 06/15 transport: use get_refs_via_connect to get refsBrandon Williams, Dec 4, 2017
  30. Junio C HamanoDec 6, 2017
  31. Brandon WilliamsDec 7, 2017
  32. 08/15 connect: discover protocol version outside of get_remote_headsBrandon Williams, Dec 4, 2017
  33. Junio C HamanoDec 7, 2017
  34. Brandon WilliamsDec 7, 2017
  35. Junio C HamanoDec 7, 2017
  36. Brandon WilliamsDec 8, 2017
  37. 13/15 connect: request remote refs using v2Brandon Williams, Dec 4, 2017
  38. 09/15 transport: store protocol versionBrandon Williams, Dec 4, 2017
  39. 11/15 serve: introduce git-serveBrandon Williams, Dec 4, 2017
  40. Junio C HamanoDec 7, 2017
  41. Brandon WilliamsDec 8, 2017
  42. 12/15 ls-refs: introduce ls-refs server commandBrandon Williams, Dec 4, 2017
  43. Philip OakleyDec 13, 2017
  44. 15/15 fetch-pack: perform a fetch using v2Brandon Williams, Dec 4, 2017
  45. 14/15 upload_pack: introduce fetch server commandBrandon Williams, Dec 4, 2017
  46. 10/15 protocol: introduce enum protocol_version value protocol_v2Brandon Williams, Dec 4, 2017
  47. 05/15 upload-pack: factor out processing linesBrandon Williams, Dec 4, 2017

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.