From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
Jason Paller-Rzepka <jasonpr@google.com>,
Stefan Beller <sbeller@google.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Multiple fetches when unshallowing a shallow clone
Date: Sun, 6 Dec 2015 01:37:19 -0500 [thread overview]
Message-ID: <20151206063718.GA549@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqmvtons4j.fsf@gitster.mtv.corp.google.com>
On Sat, Dec 05, 2015 at 08:00:28PM -0800, Junio C Hamano wrote:
> > I suppose followtags feature has been around long enough that we can
> > simply trust that and skip the second fetch?
>
> Hmmmm, I wonder why the code needs the backfill fetch while talking
> to a server that has the include-tag capability, then?
The logic in find_non_local_tags makes no sense to me.
After we do the first fetch, we call this function to find out if there
are any tags we need to pick up. We iterate through the list of refs
given to us by the remote (including peeled lines), and do:
if (ends_with(ref->name, "^{}")) {
if (item && !has_sha1_file(ref->old_sha1) &&
!will_fetch(head, ref->old_sha1) &&
!has_sha1_file(item->util) &&
!will_fetch(head, item->util))
item->util = NULL;
...
}
where "ref" is the peeled line (i.e., the pointed-to commit), and "item"
is the preceding line (i.e., the tag itself) with util set to its sha1.
Any such item whose util survives as non-NULL is fetched in the backfill
step.
So I'd think the logic for backfilling a given tag should be:
1. We have the peeled object, and...
2. We don't currently have the tag pointing to it, and...
3. We are not already going to fetch it.
You could write that as:
if (has_sha1_file(ref->old_sha1) &&
!has_sha1_file(item->util) &&
!will_fetch(head, item->util))
Of course the conditional in the code is "should we skip the backfill",
the negation. So using De Morgan's laws, we'd write:
if (!has_sha1_file(ref->old_sha1) ||
has_sha1_file(item->util) ||
will_fetch(head, item->util))
Which is quite a bit different than what is there. I'm not sure at all
what the "will_fetch(head, ref->old_sha1)" is doing. In fact, for the
backfill step, it looks like we feed an empty "head" list, so the
!will_fetch() is always true.
And indeed, replacing the logic with what I wrote does make the backfill
go away in my test case. But it's so far from what is there that I feel
like I must be missing something.
-Peff
next prev parent reply other threads:[~2015-12-06 6:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 19:35 Multiple fetches when unshallowing a shallow clone Jason Paller-Rzepka
2015-12-04 20:46 ` Stefan Beller
2015-12-04 21:27 ` Jeff King
2015-12-04 21:36 ` Stefan Beller
2015-12-04 21:38 ` Jason Paller-Rzepka
2015-12-04 21:50 ` Stefan Beller
2015-12-04 21:51 ` Jeff King
2015-12-04 22:45 ` Junio C Hamano
2015-12-05 5:33 ` Duy Nguyen
2015-12-06 4:00 ` Junio C Hamano
2015-12-06 6:37 ` Jeff King [this message]
2015-12-06 7:01 ` Jeff King
2015-12-06 10:46 ` Duy Nguyen
2015-12-07 19:57 ` Jason Paller-Rzepka
[not found] ` <CACs8u9RzUVWw2Ld1K7JeO7Eci114JEiML8bbGy96m4pZZk=FnA@mail.gmail.com>
2015-12-07 21:21 ` Duy Nguyen
2015-12-07 21:27 ` Junio C Hamano
2015-12-07 21:42 ` Jeff King
2015-12-04 21:57 ` Junio C Hamano
2015-12-04 22:10 ` 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=20151206063718.GA549@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jasonpr@google.com \
--cc=pclouds@gmail.com \
--cc=sbeller@google.com \
/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).