git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Change "refs/" references to symbolic constants
Date: Tue, 2 Oct 2007 15:11:04 -0400	[thread overview]
Message-ID: <20071002191104.GA7901@coredump.intra.peff.net> (raw)
In-Reply-To: <200710021916.44388.andyparkins@gmail.com>

On Tue, Oct 02, 2007 at 07:16:43PM +0100, Andy Parkins wrote:

> Changed repeated use of the same constants for the ref paths to be
> symbolic constants.  I've defined them in refs.h

I've manually inspected the patch. Comments are below.

> -		if (prefixcmp(head, "refs/heads/"))
> -			die("HEAD not found below refs/heads!");
> -		head += 11;
> +		if (prefixcmp(head, PATH_REFS_HEADS))
> +			die("HEAD not found below " PATH_REFS_HEADS "!");
> +		head += STRLEN_PATH_REFS_HEADS;

This slightly changes the message (extra "/"), but I don't think that is
a big deal...

> -	strcpy(path + len, "refs");
> +	strcpy(path + len, PATH_REFS);
>  	safe_create_dir(path, 1);
> -	strcpy(path + len, "refs/heads");
> +	strcpy(path + len, PATH_REFS_HEADS);
>  	safe_create_dir(path, 1);
> -	strcpy(path + len, "refs/tags");
> +	strcpy(path + len, PATH_REFS_TAGS);
>  	safe_create_dir(path, 1);

...but here it's not immediately obvious if the extra trailing "/" is
OK. Looks like the path just gets handed off to system calls trhough
safe_create_dir, and they are happy with the trailing slash. But it is a
behavior change.

> -		strcpy(path + len, "refs");
> +		strcpy(path + len, PATH_REFS);
>  		adjust_shared_perm(path);
> -		strcpy(path + len, "refs/heads");
> +		strcpy(path + len, PATH_REFS_HEADS);
>  		adjust_shared_perm(path);
> -		strcpy(path + len, "refs/tags");
> +		strcpy(path + len, PATH_REFS_TAGS);
>  		adjust_shared_perm(path);

And of course ditto here.

> -		if (snprintf(ref, sizeof(ref), "refs/tags/%s", *p)
> +		if (snprintf(ref, sizeof(ref), PATH_REFS_TAGS"%s", *p)

I find the 'PATH_REFS_TAGS "%s"' (with a space) you used earlier a
little easier to read.

> -	if (len < 5 || memcmp(name, "refs/", 5))
> +	if (len < STRLEN_PATH_REFS || memcmp(name, PATH_REFS, STRLEN_PATH_REFS))

I imagine this was one of the times you mentioned before where prefixcmp
would be more readable. I would agree.

> -	strcpy(posn, "/objects/");
> +	strcpy(posn, "/" PATH_OBJECTS);
>  	posn += 9;

should be posn += 1 + STRLEN_PATH_OBJECTS ?

> -	url = xmalloc(strlen(repo->base) + 64);
> -	sprintf(url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
> +	url = xmalloc(strlen(repo->base) + STRLEN_PATH_OBJECTS + 56);
> +	sprintf(url, "%s/" PATH_OBJECTS "pack/pack-%s.idx", repo->base, hex);

The '56' is still quite hard to verify as correct ("/" + "pack/pack-" +
".idx" + "\0"). But I wonder if trying to fix that will just make it
harder to read (perhaps a comment is in order?).

Or maybe using a strbuf here would be much more obviously correct?

> -	url = xmalloc(strlen(base) + 31);
> -	sprintf(url, "%s/objects/info/http-alternates", base);
> +	url = xmalloc(strlen(base) + STRLEN_PATH_OBJECTS + 23);
> +	sprintf(url, "%s/" PATH_OBJECTS "info/http-alternates", base);

Also a potential strbuf. Ther are more of this same form, but I'm not
going to bother pointing out each one.

> -- 
> 1.5.3.rc5.11.g312e

Man that was tedious. But I think every other change is purely
syntactic, so there shouldn't be any bugs.

-Peff

  reply	other threads:[~2007-10-02 19:11 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29 12:59 [PATCH 1/2] Change "refs/" references to symbolic constants Andy Parkins
2007-10-01 20:41 ` Andy Parkins
2007-10-02  1:16   ` Jeff King
2007-10-02  8:41     ` Andy Parkins
2007-10-02 15:58       ` Jeff King
2007-10-02 18:16         ` [PATCH] " Andy Parkins
2007-10-02 19:11           ` Jeff King [this message]
2007-10-02 19:47             ` Junio C Hamano
2007-10-02 20:48               ` Jeff King
2007-10-03  0:22                 ` Junio C Hamano
2007-10-03  2:58                   ` Jeff King
2007-10-03  4:05                     ` Johannes Schindelin
2007-10-03  4:30                       ` Jeff King
2007-10-03 11:30                       ` Andreas Ericsson
2007-10-03  7:37                 ` Andy Parkins
2007-10-03  7:50             ` Andy Parkins
2007-10-03 11:13               ` Andy Parkins
2007-10-02 17:59       ` [PATCH 1/2] " Junio C Hamano
2007-10-03  7:40         ` Andy Parkins
  -- strict thread matches above, loose matches on Subject: below --
2007-02-19 18:39 [PATCH] " Andy Parkins
2007-02-19 18:55 ` Bill Lear
2007-02-19 20:50   ` Krzysztof Halasa
2007-02-19 20:56     ` Shawn O. Pearce
2007-02-19 20:07 ` Junio C Hamano
2007-02-19 20:12   ` Shawn O. Pearce
2007-02-19 22:08   ` Johannes Schindelin
2007-02-20  8:41   ` Andy Parkins
2007-02-20  9:04     ` Junio C Hamano
2007-02-20  9:42   ` Andy Parkins
2007-02-20  9:50     ` Junio C Hamano
2007-02-20 10:21       ` Andy Parkins
2007-02-20 10:30         ` Junio C Hamano
2007-02-20 10:57           ` Andy Parkins
2007-02-20 11:37             ` Johannes Schindelin
2007-02-20 12:24               ` Simon 'corecode' Schubert
2007-02-20 13:26                 ` Johannes Schindelin
2007-02-20 13:26               ` Andy Parkins
2007-02-20 15:46             ` Nicolas Pitre

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=20071002191104.GA7901@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=andyparkins@gmail.com \
    --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).