From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org, Samuel Tardieu <sam@rfc1149.net>
Subject: Re: [PATCH] remote.c: Fix overtight refspec validation
Date: Fri, 21 Mar 2008 16:59:06 -0700 [thread overview]
Message-ID: <7vy78bmxx1.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0803211840480.19665@iabervon.org> (Daniel Barkalow's message of "Fri, 21 Mar 2008 19:12:15 -0400 (EDT)")
Daniel Barkalow <barkalow@iabervon.org> writes:
>> + /*
>> + * Do we want to validate LHS?
>> + ...
>> + * Hence we check non-empty LHS for fetch, and
>> + * colonless or glob LHS for push here.
>> + */
>
> Wouldn't this be clearer and not meaningfully harder in
> parse_fetch_refspec and parse_push_refspec?
Do you mean you want the callers of this internal implementation to also
loop over the input set of refs? I think that would be more complex code
but I do not see much gain by doing so.
>> + if (fetch ? (*rs[i].src) : (!rhs || is_glob)) {
>
> This is an odd combination of locals and struct members.
> : (!rs[i].dst || rs[i].pattern) {
Sorry, I do not understand what's wrong about it.
!!rhs === (did we see a colon) === !!rs[].dst
is_glob === (did they both end with "/*") === rs[].pattern
They are equivalent, and local variables are primarily what the logic
works on and bases its decisions to store what in rs[] structures.
Ahh... do you mean:
(*rs[i].src) === (is lhs non empty?) === !!llen
I guess using "llen" there is more consistent and is moderately cleaner.
Perhaps squash this as a clean-up?
diff --git a/remote.c b/remote.c
index 4117bfc..86113b7 100644
--- a/remote.c
+++ b/remote.c
@@ -453,7 +453,7 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
* "empty" for removal) in LHS, and we cannot check
* for error until it actually gets used.
*/
- if (fetch ? (*rs[i].src) : (!rhs || is_glob)) {
+ if (fetch ? llen : (!rhs || is_glob)) {
st = check_ref_format(rs[i].src);
if (st && st != CHECK_REF_FORMAT_ONELEVEL)
goto invalid;
next prev parent reply other threads:[~2008-03-21 23:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 0:54 [PATCH] Permit refspec source side to parse as a sha1 Daniel Barkalow
2008-03-21 4:10 ` Junio C Hamano
2008-03-21 4:50 ` Junio C Hamano
2008-03-21 5:09 ` Daniel Barkalow
2008-03-21 5:30 ` Junio C Hamano
2008-03-21 5:57 ` Daniel Barkalow
2008-03-21 6:26 ` Junio C Hamano
2008-03-21 16:08 ` Daniel Barkalow
2008-03-21 22:17 ` [PATCH] remote.c: Fix overtight refspec validation Junio C Hamano
2008-03-21 23:12 ` Daniel Barkalow
2008-03-21 23:59 ` Junio C Hamano [this message]
2008-03-22 0:36 ` Daniel Barkalow
2008-03-22 19:48 ` Junio C Hamano
2008-03-22 20:45 ` Daniel Barkalow
2008-03-26 1:45 ` Linus Torvalds
2008-03-26 3:31 ` Junio C Hamano
2008-03-26 4:11 ` Junio C Hamano
2008-03-26 5:42 ` Daniel Barkalow
2008-03-26 5:46 ` Junio C Hamano
2008-03-26 6:22 ` Jeff King
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=7vy78bmxx1.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=sam@rfc1149.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).