git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] git_connect: factor out discovery of the protocol and its parts
Date: Tue, 05 Nov 2013 22:22:51 +0100	[thread overview]
Message-ID: <527961AB.2010606@kdbg.org> (raw)
In-Reply-To: <527958E1.2080805@web.de>

Am 05.11.2013 21:45, schrieb Torsten Bögershausen:
> On 2013-11-05 20.39, Johannes Sixt wrote:
> Thanks for picking this up, please see some minor nits inline,
> and git_connect() is at the end
> 
>> -struct child_process *git_connect(int fd[2], const char *url_orig,
>> -				  const char *prog, int flags)
>> +static enum protocol parse_connect_url(const char *url_orig, char **ret_host,
>> +				       char **ret_port, char **ret_path)
>>  {
>>  	char *url;
>>  	char *host, *path;
>>  	char *end;
> Can we put all the char * into one single line?

The idea here was to keep the diff minimal, and that further slight
cleanups should be combined with subsequent rewrites that should happen
to this function.

>>  	int c;
>> @@ -645,6 +628,49 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
>>  	if (protocol == PROTO_SSH && host != url)
>>  		port = get_port(end);
>>  
>> +	*ret_host = xstrdup(host);
>> +	if (port)
>> +		*ret_port = xstrdup(port);
>> +	else
>> +		*ret_port = NULL;
>> +	if (free_path)
>> +		*ret_path = path;
>> +	else
>> +		*ret_path = xstrdup(path);
>> +	free(url);
>> +	return protocol;
>> +}
>> +
>> +static struct child_process no_fork;
>> +
>> +/*
>> + * This returns a dummy child_process if the transport protocol does not
>> + * need fork(2), or a struct child_process object if it does.  Once done,
>> + * finish the connection with finish_connect() with the value returned from
>> + * this function (it is safe to call finish_connect() with NULL to support
>> + * the former case).
>> + *
>> + * If it returns, the connect is successful; it just dies on errors (this
>> + * will hopefully be changed in a libification effort, to return NULL when
>> + * the connection failed).
>> + */
>> +struct child_process *git_connect(int fd[2], const char *url,
>> +				  const char *prog, int flags)
>> +{
>> +	char *host, *path;
>> +	struct child_process *conn = &no_fork;
>> +	enum protocol protocol;
>> +	char *port;
>> +	const char **arg;
>> +	struct strbuf cmd = STRBUF_INIT;
>> +
>> +	/* Without this we cannot rely on waitpid() to tell
>> +	 * what happened to our children.
>> +	 */
>> +	signal(SIGCHLD, SIG_DFL);
>> +
>> +	protocol = parse_connect_url(url, &host, &port, &path);
>> +
>>  	if (protocol == PROTO_GIT) {
>>  		/* These underlying connection commands die() if they
>>  		 * cannot connect.
>> @@ -666,9 +692,9 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
>>  			     prog, path, 0,
>>  			     target_host, 0);
>>  		free(target_host);
> This is hard to see in the diff, I think we don't need target_host any more.

I though that as well first, but no, we still need it. Further rewrites
are needed that move the port discovery from git_proxy_connect() and
git_tcp_connect() to the new parse_connect_url() before target_host can
go away. And even then it is questionable because target_host is used in
an error message and is intended to reflect the original combined
host+port portion of the URL, if I read the code correctly.

>> -		free(url);
>> -		if (free_path)
>> -			free(path);
>> +		free(host);
>> +		free(port);
>> +		free(path);
>>  		return conn;
>>  	}
>>  
>> @@ -709,9 +735,9 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
>>  	fd[0] = conn->out; /* read from child's stdout */
>>  	fd[1] = conn->in;  /* write to child's stdin */
>>  	strbuf_release(&cmd);
>> -	free(url);
>> -	if (free_path)
>> -		free(path);
> 
> This "end of function, free everything and return conn",
> could we re-arange so that it is in the code only once ?

That would be quite simple now; just place the part after the first
return into the else branch. That opens opportunities to move variable
declarations from the top of the function into the else branch.

But all of these changes should go into a separate commit, IMO, so that
the function splitting that happens here can be verified more easily.

-- Hannes

  reply	other threads:[~2013-11-05 21:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 21:20 [PATCH V4] git clone: is an URL local or ssh Torsten Bögershausen
2013-11-05  7:14 ` Johannes Sixt
2013-11-05 19:35   ` [PATCH 1/2] git_connect: remove artificial limit of a remote command Johannes Sixt
2013-11-05 19:39     ` [PATCH 2/2] git_connect: factor out discovery of the protocol and its parts Johannes Sixt
2013-11-05 20:45       ` Torsten Bögershausen
2013-11-05 21:22         ` Johannes Sixt [this message]
2013-11-06 15:31           ` Torsten Bögershausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527961AB.2010606@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).