Since day one, function git_connect() had a limit on the command line of
the command that is invoked to make a connection. 7a33bcbe converted the
code that constructs the command to strbuf. This would have been the
right time to remove the limit, but it did not happen. Remove it now.
git_connect() uses start_command() to invoke the command; consequently,
the limits of the system still apply, but are diagnosed only at execve()
time. But these limits are more lenient than the 1K that git_connect()
imposed.
Signed-off-by: Johannes Sixt <j6t@xxxxxxxx>
---
Am 05.11.2013 08:14, schrieb Johannes Sixt:
> Can you please make this into a series of small patches so that we can
> more easily see the good and the bad parts? One of the patches could be a
> clean-up of the current protocol determination and URL dissection, which
> is indigestible spaghetti right now.
Maybe start with these two.
connect.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index 06e88b0..6cc1f8d 100644
--- a/connect.c
+++ b/connect.c
@@ -527,8 +527,6 @@ static struct child_process *git_proxy_connect(int fd[2], char *host)
return proxy;
}
-#define MAX_CMD_LEN 1024
-
static char *get_port(char *host)
{
char *end;
@@ -570,7 +568,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
int free_path = 0;
char *port = NULL;
const char **arg;
- struct strbuf cmd;
+ struct strbuf cmd = STRBUF_INIT;
/* Without this we cannot rely on waitpid() to tell
* what happened to our children.
@@ -676,12 +674,9 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
conn = xcalloc(1, sizeof(*conn));
- strbuf_init(&cmd, MAX_CMD_LEN);
strbuf_addstr(&cmd, prog);
strbuf_addch(&cmd, ' ');
sq_quote_buf(&cmd, path);
- if (cmd.len >= MAX_CMD_LEN)
- die("command line too long");
conn->in = conn->out = -1;
conn->argv = arg = xcalloc(7, sizeof(*arg));
--
1.8.4.33.gd68f7e8
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html