From: Paolo Bonzini <paolo.bonzini@lu.unisi.ch>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: bonzini@gnu.org, git@vger.kernel.org
Subject: Re: [PATCH 1/3] git-branch: add --track and --no-track options
Date: Mon, 05 Mar 2007 18:22:14 +0100 [thread overview]
Message-ID: <45EC51C6.5080505@lu.unisi.ch> (raw)
In-Reply-To: <Pine.LNX.4.63.0703051812030.22628@wbgn013.biozentrum.uni-wuerzburg.de>
> Yes, you also check real_ref instead of checking if dwim_ref() returned 0.
> I feel a little bit uneasy about that, since there is no guarantee that
> these values are left untouched, whereas the return value is guaranteed to
> behave as expected.
There is. The man page says "Scanning stops when an input character does not match such a format character." Scanning includes not processing %n elements, either.
Regarding dwim_ref, dwim_ref says:
int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
const char **p, *r;
int refs_found = 0;
*ref = NULL;
and since this "*ref" is not used anyway in the rest of the routine, I figured out that it's part of the interface to set "*ref" to NULL if no ref is found. Of course it could help (hint hint) if extern functions had a comment stating the interface.
I see however that I also have a "real_ref = NULL" that is actually pointless; I can take it away of course.
> I also feel a little uneasy about having to parse a format in order to
> parse a string, when you know what that string should look like. For
> example, you could make the code even more compact by asking
> "(p = strstr(value, "/*:refs/remotes/"))".
Go down this way and you will say that printf is useless too.
Paolo
next prev parent reply other threads:[~2007-03-05 17:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-05 8:57 [PATCH 1/3] git-branch: add --track and --no-track options Paolo Bonzini
2007-03-05 14:50 ` Johannes Schindelin
2007-03-05 15:22 ` Paolo Bonzini
2007-03-05 16:09 ` Johannes Schindelin
2007-03-05 17:22 ` Paolo Bonzini
2007-03-05 15:36 ` Paolo Bonzini
2007-03-05 15:58 ` Johannes Schindelin
2007-03-05 16:54 ` Paolo Bonzini
2007-03-05 17:16 ` Johannes Schindelin
2007-03-05 17:22 ` Paolo Bonzini [this message]
2007-03-05 18:37 ` Johannes Schindelin
2007-03-05 21:19 ` Paolo Bonzini
2007-03-05 21:27 ` Junio C Hamano
2007-03-06 7:23 ` Paolo Bonzini
2007-03-05 23:09 ` Johannes Schindelin
2007-03-06 6:45 ` Junio C Hamano
2007-03-06 7:26 ` Paolo Bonzini
2007-03-06 7:40 ` Junio C Hamano
2007-03-06 7:48 ` Paolo Bonzini
2007-03-06 8:22 ` Junio C Hamano
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=45EC51C6.5080505@lu.unisi.ch \
--to=paolo.bonzini@lu.unisi.ch \
--cc=Johannes.Schindelin@gmx.de \
--cc=bonzini@gnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.