|
|
|
#include "cache.h"
|
|
|
|
#include "repository.h"
|
|
|
|
#include "config.h"
|
|
|
|
#include "pkt-line.h"
|
|
|
|
#include "version.h"
|
|
|
|
#include "strvec.h"
|
|
|
|
#include "ls-refs.h"
|
|
|
|
#include "protocol-caps.h"
|
|
|
|
#include "serve.h"
|
|
|
|
#include "upload-pack.h"
|
|
|
|
|
|
|
|
static int advertise_sid = -1;
|
|
|
|
static int client_hash_algo = GIT_HASH_SHA1;
|
|
|
|
|
|
|
|
static int always_advertise(struct repository *r,
|
|
|
|
struct strbuf *value)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int agent_advertise(struct repository *r,
|
|
|
|
struct strbuf *value)
|
|
|
|
{
|
|
|
|
if (value)
|
|
|
|
strbuf_addstr(value, git_user_agent_sanitized());
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int object_format_advertise(struct repository *r,
|
|
|
|
struct strbuf *value)
|
|
|
|
{
|
|
|
|
if (value)
|
|
|
|
strbuf_addstr(value, r->hash_algo->name);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void object_format_receive(struct repository *r,
|
|
|
|
const char *algo_name)
|
|
|
|
{
|
|
|
|
if (!algo_name)
|
|
|
|
die("object-format capability requires an argument");
|
|
|
|
|
|
|
|
client_hash_algo = hash_algo_by_name(algo_name);
|
|
|
|
if (client_hash_algo == GIT_HASH_UNKNOWN)
|
|
|
|
die("unknown object format '%s'", algo_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int session_id_advertise(struct repository *r, struct strbuf *value)
|
|
|
|
{
|
|
|
|
if (advertise_sid == -1 &&
|
|
|
|
git_config_get_bool("transfer.advertisesid", &advertise_sid))
|
|
|
|
advertise_sid = 0;
|
|
|
|
if (!advertise_sid)
|
|
|
|
return 0;
|
|
|
|
if (value)
|
|
|
|
strbuf_addstr(value, trace2_session_id());
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void session_id_receive(struct repository *r,
|
|
|
|
const char *client_sid)
|
|
|
|
{
|
|
|
|
if (!client_sid)
|
|
|
|
client_sid = "";
|
|
|
|
trace2_data_string("transfer", NULL, "client-sid", client_sid);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct protocol_capability {
|
|
|
|
/*
|
|
|
|
* The name of the capability. The server uses this name when
|
|
|
|
* advertising this capability, and the client uses this name to
|
|
|
|
* specify this capability.
|
|
|
|
*/
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function queried to see if a capability should be advertised.
|
|
|
|
* Optionally a value can be specified by adding it to 'value'.
|
|
|
|
* If a value is added to 'value', the server will advertise this
|
|
|
|
* capability as "<name>=<value>" instead of "<name>".
|
|
|
|
*/
|
|
|
|
int (*advertise)(struct repository *r, struct strbuf *value);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function called when a client requests the capability as a command.
|
|
|
|
* Will be provided a struct packet_reader 'request' which it should
|
|
|
|
* use to read the command specific part of the request. Every command
|
|
|
|
* MUST read until a flush packet is seen before sending a response.
|
|
|
|
*
|
|
|
|
* This field should be NULL for capabilities which are not commands.
|
|
|
|
*/
|
|
|
|
int (*command)(struct repository *r, struct packet_reader *request);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function called when a client requests the capability as a
|
|
|
|
* non-command. This may be NULL if the capability does nothing.
|
|
|
|
*
|
|
|
|
* For a capability of the form "foo=bar", the value string points to
|
|
|
|
* the content after the "=" (i.e., "bar"). For simple capabilities
|
|
|
|
* (just "foo"), it is NULL.
|
|
|
|
*/
|
|
|
|
void (*receive)(struct repository *r, const char *value);
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct protocol_capability capabilities[] = {
|
|
|
|
{
|
|
|
|
.name = "agent",
|
|
|
|
.advertise = agent_advertise,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "ls-refs",
|
|
|
|
.advertise = ls_refs_advertise,
|
|
|
|
.command = ls_refs,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "fetch",
|
|
|
|
.advertise = upload_pack_advertise,
|
|
|
|
.command = upload_pack_v2,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "server-option",
|
|
|
|
.advertise = always_advertise,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "object-format",
|
|
|
|
.advertise = object_format_advertise,
|
|
|
|
.receive = object_format_receive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "session-id",
|
|
|
|
.advertise = session_id_advertise,
|
|
|
|
.receive = session_id_receive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "object-info",
|
|
|
|
.advertise = always_advertise,
|
|
|
|
.command = cap_object_info,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
void protocol_v2_advertise_capabilities(void)
|
|
|
|
{
|
|
|
|
struct strbuf capability = STRBUF_INIT;
|
|
|
|
struct strbuf value = STRBUF_INIT;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* serve by default supports v2 */
|
|
|
|
packet_write_fmt(1, "version 2\n");
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capabilities); i++) {
|
|
|
|
struct protocol_capability *c = &capabilities[i];
|
|
|
|
|
|
|
|
if (c->advertise(the_repository, &value)) {
|
|
|
|
strbuf_addstr(&capability, c->name);
|
|
|
|
|
|
|
|
if (value.len) {
|
|
|
|
strbuf_addch(&capability, '=');
|
|
|
|
strbuf_addbuf(&capability, &value);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_addch(&capability, '\n');
|
|
|
|
packet_write(1, capability.buf, capability.len);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_reset(&capability);
|
|
|
|
strbuf_reset(&value);
|
|
|
|
}
|
|
|
|
|
|
|
|
packet_flush(1);
|
|
|
|
strbuf_release(&capability);
|
|
|
|
strbuf_release(&value);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct protocol_capability *get_capability(const char *key, const char **value)
|
|
|
|
{
|
|
|
|
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))
|
|
|
|
continue;
|
|
|
|
if (!*out) {
|
|
|
|
*value = NULL;
|
|
|
|
return c;
|
|
|
|
}
|
|
|
|
if (*out++ == '=') {
|
|
|
|
*value = out;
|
|
|
|
return c;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int receive_client_capability(const char *key)
|
|
|
|
{
|
|
|
|
const char *value;
|
|
|
|
const struct protocol_capability *c = get_capability(key, &value);
|
|
|
|
|
serve: reject commands used as capabilities
Our table of v2 "capabilities" contains everything we might tell the
client we support. But there are differences in how we expect the client
to respond. Some of the entries are true capabilities (i.e., we expect
the client to say "yes, I support this"), and some are ones we expect
them to send as commands (with "command=ls-refs" or similar).
When we receive a capability used as a command, we complain about that.
But when we receive a command used as a capability (e.g., just "ls-refs"
in a pkt-line by itself), we silently ignore it.
This isn't really hurting anything (clients shouldn't send it, and we'll
ignore it), but we can tighten up the protocol to match what we expect
to happen.
There are two new tests here. The first one checks a capability used as
a command, which already passes. The second tests a command as a
capability, which this patch fixes.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
if (!c || c->command || !c->advertise(the_repository, NULL))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (c->receive)
|
|
|
|
c->receive(the_repository, value);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_command(const char *key, struct protocol_capability **command)
|
|
|
|
{
|
|
|
|
const char *out;
|
|
|
|
|
|
|
|
if (skip_prefix(key, "command=", &out)) {
|
|
|
|
const char *value;
|
|
|
|
struct protocol_capability *cmd = get_capability(out, &value);
|
|
|
|
|
|
|
|
if (*command)
|
|
|
|
die("command '%s' requested after already requesting command '%s'",
|
|
|
|
out, (*command)->name);
|
serve: reject bogus v2 "command=ls-refs=foo"
When we see a line from the client like "command=ls-refs", we parse
everything after the equals sign as a capability, which we check against
our capabilities table. If we don't recognize the command (e.g.,
"command=foo"), we'll reject it.
But in parse_command(), we use the same get_capability() parser for
parsing non-command lines. So if we see "command=ls-refs=foo", we will
feed "ls-refs=foo" to get_capability(), which will say "OK, that's
ls-refs, with value 'foo'". But then we simply ignore the value
entirely.
The client is violating the spec here, which says:
command = PKT-LINE("command=" key LF)
key = 1*(ALPHA | DIGIT | "-_")
I.e., the key is not even allowed to have an equals sign in it. Whereas
a real non-command capability does allow a value:
capability = PKT-LINE(key[=value] LF)
So by reusing the same get_capability() parser, we are mixing up the
"key" and "capability" tokens. However, since that parser tells us
whether it saw an "=", we can still use it; we just need to reject any
input that produces a non-NULL value field.
The current behavior isn't really hurting anything (the client should
never send such a request, and if it does, we just ignore the "value"
part). But since it does violate the spec, let's tighten it up to
prevent any surprising behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
if (!cmd || !cmd->advertise(the_repository, NULL) || !cmd->command || value)
|
|
|
|
die("invalid command '%s'", out);
|
|
|
|
|
|
|
|
*command = cmd;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum request_state {
|
|
|
|
PROCESS_REQUEST_KEYS,
|
|
|
|
PROCESS_REQUEST_DONE,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int process_request(void)
|
|
|
|
{
|
|
|
|
enum request_state state = PROCESS_REQUEST_KEYS;
|
|
|
|
struct packet_reader reader;
|
|
|
|
int seen_capability_or_command = 0;
|
|
|
|
struct protocol_capability *command = NULL;
|
|
|
|
|
|
|
|
packet_reader_init(&reader, 0, NULL, 0,
|
|
|
|
PACKET_READ_CHOMP_NEWLINE |
|
pack-protocol.txt: accept error packets in any context
In the Git pack protocol definition, an error packet may appear only in
a certain context. However, servers can face a runtime error (e.g. I/O
error) at an arbitrary timing. This patch changes the protocol to allow
an error packet to be sent instead of any packet.
Without this protocol spec change, when a server cannot process a
request, there's no way to tell that to a client. Since the server
cannot produce a valid response, it would be forced to cut a connection
without telling why. With this protocol spec change, the server can be
more gentle in this situation. An old client may see these error packets
as an unexpected packet, but this is not worse than having an unexpected
EOF.
Following this protocol spec change, the error packet handling code is
moved to pkt-line.c. Implementation wise, this implementation uses
pkt-line to communicate with a subprocess. Since this is not a part of
Git protocol, it's possible that a packet that is not supposed to be an
error packet is mistakenly parsed as an error packet. This error packet
handling is enabled only for the Git pack protocol parsing code
considering this.
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
|
|
|
PACKET_READ_GENTLE_ON_EOF |
|
|
|
|
PACKET_READ_DIE_ON_ERR_PACKET);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if the client closed their end before sending another
|
|
|
|
* request. If so we can terminate the connection.
|
|
|
|
*/
|
|
|
|
if (packet_reader_peek(&reader) == PACKET_READ_EOF)
|
|
|
|
return 1;
|
pack-protocol.txt: accept error packets in any context
In the Git pack protocol definition, an error packet may appear only in
a certain context. However, servers can face a runtime error (e.g. I/O
error) at an arbitrary timing. This patch changes the protocol to allow
an error packet to be sent instead of any packet.
Without this protocol spec change, when a server cannot process a
request, there's no way to tell that to a client. Since the server
cannot produce a valid response, it would be forced to cut a connection
without telling why. With this protocol spec change, the server can be
more gentle in this situation. An old client may see these error packets
as an unexpected packet, but this is not worse than having an unexpected
EOF.
Following this protocol spec change, the error packet handling code is
moved to pkt-line.c. Implementation wise, this implementation uses
pkt-line to communicate with a subprocess. Since this is not a part of
Git protocol, it's possible that a packet that is not supposed to be an
error packet is mistakenly parsed as an error packet. This error packet
handling is enabled only for the Git pack protocol parsing code
considering this.
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
|
|
|
reader.options &= ~PACKET_READ_GENTLE_ON_EOF;
|
|
|
|
|
|
|
|
while (state != PROCESS_REQUEST_DONE) {
|
|
|
|
switch (packet_reader_peek(&reader)) {
|
|
|
|
case PACKET_READ_EOF:
|
|
|
|
BUG("Should have already died when seeing EOF");
|
|
|
|
case PACKET_READ_NORMAL:
|
|
|
|
if (parse_command(reader.line, &command) ||
|
|
|
|
receive_client_capability(reader.line))
|
|
|
|
seen_capability_or_command = 1;
|
|
|
|
else
|
|
|
|
die("unknown capability '%s'", reader.line);
|
|
|
|
|
|
|
|
/* Consume the peeked line */
|
|
|
|
packet_reader_read(&reader);
|
|
|
|
break;
|
|
|
|
case PACKET_READ_FLUSH:
|
|
|
|
/*
|
|
|
|
* If no command and no keys were given then the client
|
|
|
|
* wanted to terminate the connection.
|
|
|
|
*/
|
|
|
|
if (!seen_capability_or_command)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The flush packet isn't consume here like it is in
|
|
|
|
* the other parts of this switch statement. This is
|
|
|
|
* so that the command can read the flush packet and
|
|
|
|
* see the end of the request in the same way it would
|
|
|
|
* if command specific arguments were provided after a
|
|
|
|
* delim packet.
|
|
|
|
*/
|
|
|
|
state = PROCESS_REQUEST_DONE;
|
|
|
|
break;
|
|
|
|
case PACKET_READ_DELIM:
|
|
|
|
/* Consume the peeked line */
|
|
|
|
packet_reader_read(&reader);
|
|
|
|
|
|
|
|
state = PROCESS_REQUEST_DONE;
|
|
|
|
break;
|
|
|
|
case PACKET_READ_RESPONSE_END:
|
|
|
|
BUG("unexpected response end packet");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!command)
|
|
|
|
die("no command requested");
|
|
|
|
|
|
|
|
if (client_hash_algo != hash_algo_by_ptr(the_repository->hash_algo))
|
|
|
|
die("mismatched object format: server %s; client %s\n",
|
|
|
|
the_repository->hash_algo->name,
|
|
|
|
hash_algos[client_hash_algo].name);
|
|
|
|
|
|
|
|
command->command(the_repository, &reader);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
void protocol_v2_serve_loop(int stateless_rpc)
|
|
|
|
{
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
if (!stateless_rpc)
|
|
|
|
protocol_v2_advertise_capabilities();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If stateless-rpc was requested then exit after
|
|
|
|
* a single request/response exchange
|
|
|
|
*/
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
if (stateless_rpc) {
|
|
|
|
process_request();
|
|
|
|
} else {
|
|
|
|
for (;;)
|
|
|
|
if (process_request())
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|