git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add support for host aliases in config files
Date: Sun, 17 Feb 2008 20:52:00 -0800	[thread overview]
Message-ID: <7vskzquarz.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0802171337000.5816@iabervon.org> (Daniel Barkalow's message of "Sun, 17 Feb 2008 13:38:51 -0500 (EST)")

Daniel Barkalow <barkalow@iabervon.org> writes:

> ..., but I'd like to get the 
> code portion out there are reviewed, at least, since I think last time, 
> the patch only got as far as a discussion of how I should explain what it 
> does.

I actually think that is the most important part to get it right
first.  I usually do not have to read the patch text to reject
an ill-conceived idea if the description is unclear and/or
unconvincing.

I think the documentation (I removed from the quote) shows the
feature is unambiguously good.

> diff --git a/remote.c b/remote.c
> index 6b56473..59338a3 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -2,6 +2,15 @@
>  #include "remote.h"
>  #include "refs.h"
>  
> +struct host {
> +	const char *name;
> +
> +	const char *base;
> +
> +	const char **alias;
> +	int alias_nr;
> +};

Extra blank lines?

> @@ -11,9 +20,32 @@ static int allocated_branches;
>  static struct branch *current_branch;
>  static const char *default_remote_name;
>  
> +static struct host **hosts;
> +static int allocated_hosts;

The allocation in remote.c file is unusual from the rest of git
that usually follow the technical/api-allocation-growing
convention (the comment unfortunately applies to the code we
already have there).

> +static const char *alias_url(const char *url)
> +{
> +	int i, j;
> +	for (i = 0; i < allocated_hosts; i++) {
> +		if (!hosts[i])
> +			continue;
> +		for (j = 0; j < hosts[i]->alias_nr; j++) {
> +			if (!prefixcmp(url, hosts[i]->alias[j])) {
> +				char *ret = malloc(strlen(hosts[i]->base) -
> +						   strlen(hosts[i]->alias[j]) +
> +						   strlen(url) + 1);
> +				strcpy(ret, hosts[i]->base);
> +				strcat(ret, url + strlen(hosts[i]->alias[j]));
> +				return ret;
> +			}

First match semantics is fine during runtime but at some point
we would want a "config file lint" that points out ambiguous
aliases perhaps?

> +static struct host *make_host(const char *name, int len)
> +{
> ...
> +	if (empty < 0) {
> +		empty = allocated_hosts;
> +		allocated_hosts += allocated_hosts ? allocated_hosts : 1;
> +		hosts = xrealloc(hosts,
> +				 sizeof(*hosts) * allocated_hosts);

This hand-rolled allocation growing is quite different from the
rest of our codebase.

> +static void add_alias(struct host *host, const char *name)
> +{
> +	int nr = host->alias_nr + 1;
> +	host->alias =
> +		xrealloc(host->alias, nr * sizeof(char *));
> +	host->alias[nr-1] = name;
> +	host->alias_nr = nr;
> +}

And this "add one-by-one" allocation, too.

> @@ -154,7 +233,7 @@ static void read_remotes_file(struct remote *remote)
>  
>  		switch (value_list) {
>  		case 0:
> -			add_url(remote, xstrdup(s));
> +			add_url_alias(remote, xstrdup(s));
>  			break;
>  		case 1:
>  			add_push_refspec(remote, xstrdup(s));
> @@ -206,7 +285,7 @@ static void read_branches_file(struct remote *remote)
>  	} else {
>  		branch = "refs/heads/master";
>  	}
> -	add_url(remote, p);
> +	add_url_alias(remote, p);
>  	add_fetch_refspec(remote, branch);
>  	remote->fetch_tags = 1; /* always auto-follow */
>  }

These two are logical and clean updates.

> @@ -236,6 +315,20 @@ static int handle_config(const char *key, const char *value)
>  		}
>  		return 0;
>  	}
> +	if (!prefixcmp(key, "host.")) {
> +		struct host *host;
> +		name = key + 5;
> +		subkey = strrchr(name, '.');
> +		if (!subkey)
> +			return 0;

This "ignore this entry" is good.  We might later want to add
host.<var> that is not about a specific host, and we would want
to be able to read a configuration that is written for such a
future version of git.

> +		host = make_host(name, subkey - name);
> +		if (!value)
> +			return 0;

This is not.

 (1) We should barf saying "host.<this-host>.<var> configuration
     should be a string", for base and rewritebase, instead of
     silently ignoring such a misconfiguration;

 (2) We should _not_ do such barfing for future variables that
     are not base nor rewritebase, so this "return" is at a
     wrong place.

So the code should do this part (perhaps with git_config_string())
first,...

> +		if (!strcmp(subkey, ".base"))
> +			host->base = xstrdup(value);
> +		else if (!strcmp(subkey, ".rewritebase"))
> +			add_alias(host, xstrdup(value));

... and then ignore anything other than host.<this-host>.{base,rewritebase}
that may mean something in future versions of git.

  parent reply	other threads:[~2008-02-18  4:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-17 18:38 [PATCH] Add support for host aliases in config files Daniel Barkalow
2008-02-17 18:48 ` Jakub Narebski
2008-02-17 18:58   ` Daniel Barkalow
2008-02-17 19:36 ` Johannes Schindelin
2008-02-18  4:52 ` Junio C Hamano [this message]
2008-02-18 19:29   ` Daniel Barkalow
  -- strict thread matches above, loose matches on Subject: below --
2008-01-25 18:39 Daniel Barkalow
2008-01-25 18:52 ` Jakub Narebski
2008-01-25 19:01   ` Junio C Hamano
2008-01-25 19:09   ` Daniel Barkalow
2008-01-25 19:33     ` Jakub Narebski
2008-01-25 19:53       ` Daniel Barkalow
2008-01-25 21:51         ` Jakub Narebski
2008-01-25 20:19       ` Junio C Hamano
2008-01-25 21:12         ` Daniel Barkalow
2008-01-25 21:48           ` Jakub Narebski

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=7vskzquarz.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    /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).