From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Kyle J. McKay" <mackyle@gmail.com>,
Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH 1/4] filter_ref: avoid overwriting ref->old_sha1 with garbage
Date: Thu, 19 Mar 2015 14:09:44 -0700 [thread overview]
Message-ID: <xmqq7fucitif.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150319203451.GA7666@peff.net> (Jeff King's message of "Thu, 19 Mar 2015 16:34:51 -0400")
Jeff King <peff@peff.net> writes:
> I wonder if the thinking in the original was that it was our
> responsibility here to make sure that ref->old_sha1 was filled in.
I am reasonably sure that is the (perhaps mistaken) reasoning behind
the use of old_sha1 as the second parameter to get_sha1_hex().
> It is
> always filled in by the caller who gives us "sought", which makes sense
> to me (this matches the rest of the "sought" entries, which come from
> reading the remote's ref list, and of course must fill in old_sha1 from
> that list).
I see that sought is populated by reading the command line of "git
fetch-pack", and for a 40-hex request ref->old_sha1 is already
filled there, so I agree that it is redundant to try filling it in
filter_refs().
Thanks.
> fetch-pack.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 655ee64..058c258 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -544,10 +544,14 @@ static void filter_refs(struct fetch_pack_args *args,
> /* Append unmatched requests to the list */
> if (allow_tip_sha1_in_want) {
> for (i = 0; i < nr_sought; i++) {
> + unsigned char sha1[20];
> +
> ref = sought[i];
> if (ref->matched)
> continue;
> - if (get_sha1_hex(ref->name, ref->old_sha1))
> + if (get_sha1_hex(ref->name, sha1) ||
> + ref->name[40] != '\0' ||
> + hashcmp(sha1, ref->old_sha1))
> continue;
>
> ref->matched = 1;
next prev parent reply other threads:[~2015-03-19 21:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-15 6:37 Bug in fetch-pack.c, please confirm Kyle J. McKay
2015-03-15 7:27 ` Junio C Hamano
2015-03-15 7:30 ` Junio C Hamano
2015-03-15 22:21 ` Kyle J. McKay
2015-03-16 1:13 ` Jeff King
2015-03-19 17:41 ` Junio C Hamano
2015-03-19 18:55 ` Jeff King
2015-03-19 19:01 ` Junio C Hamano
2015-03-19 20:31 ` Jeff King
2015-03-19 20:34 ` [PATCH 1/4] filter_ref: avoid overwriting ref->old_sha1 with garbage Jeff King
2015-03-19 21:09 ` Junio C Hamano [this message]
2015-03-19 20:37 ` [PATCH 2/4] filter_ref: make a copy of extra "sought" entries Jeff King
2015-03-19 20:38 ` [PATCH 3/4] fetch_refs_via_pack: free extra copy of refs Jeff King
2015-03-19 20:39 ` [PATCH 4/4] fetch-pack: remove dead assignment to ref->new_sha1 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=xmqq7fucitif.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mackyle@gmail.com \
--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 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.