From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>
Subject: Re: [PATCH] Change "refs/" references to symbolic constants
Date: Wed, 3 Oct 2007 08:50:18 +0100 [thread overview]
Message-ID: <200710030850.19614.andyparkins@gmail.com> (raw)
In-Reply-To: <20071002191104.GA7901@coredump.intra.peff.net>
On Tuesday 2007 October 02, Jeff King wrote:
> > - 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...
Actually, I felt that was an improvement. Personally I always like paths
shown to a user to have the trailing slash so that they can be clear that it
is a path not a file.
> > - 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.
It's been a while, but at the time I did it I think I checked
safe_create_dir() to be sure that it was happy with trailing slashes.
> I find the 'PATH_REFS_TAGS "%s"' (with a space) you used earlier a
> little easier to read.
Okay.
> > - 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.
It is. A patch to fix these is in my pending list.
> > - strcpy(posn, "/objects/");
> > + strcpy(posn, "/" PATH_OBJECTS);
> > posn += 9;
>
> should be posn += 1 + STRLEN_PATH_OBJECTS ?
Well spotted. Fixed.
> > - 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?).
I put a comment above the other changes like this in the same file, but
thought I was being overly verbose putting it in every single time. I'm
happy to copy the comment around in the file though.
> 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.
I was trying, as far as I could, to leave the code unchanged. If strbuf would
be better I think I'd rather do it with another patch after this.
> Man that was tedious. But I think every other change is purely
> syntactic, so there shouldn't be any bugs.
It really was wasn't it? :-) While I was trying to find that bug that you
caught yesterday I thought I was going blind. I have this to say though:
thank heaven for git's colourised diffs. Those that think coloured output is
just for prettiness sake should try that review with and without.
Thank you for expending so much effort on this, it is appreciated.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
next prev parent reply other threads:[~2007-10-03 7:50 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
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 [this message]
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=200710030850.19614.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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).