All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] upload-pack: do not lazy-fetch "have" objects
Date: Wed, 15 Jul 2020 15:55:18 -0700	[thread overview]
Message-ID: <xmqqpn8wie21.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200715223112.2018556-1-jonathantanmy@google.com> (Jonathan Tan's message of "Wed, 15 Jul 2020 15:31:12 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

> When upload-pack receives a request containing "have" hashes, it (among
> other things) checks if the served repository has the corresponding
> objects. However, it does not do so with the
> OBJECT_INFO_SKIP_FETCH_OBJECT flag, so if serving a partial clone, a
> lazy fetch will be triggered first.

OK.  

Fixing issues hit by real users reactively is a necessary and good
thing, but this is not the first time we patch callers of
has_object_file() for this kind of "we are merely trying to
determine the boundary of what we have, so that we know what we need
to add to this repository" queries, I am afraid.

Perhaps it is a good idea to sweep all the hits from "git grep -e
has_object_file \*.c" and audit the codebase to see if there are
other problematic ones?

For example, list-objects.c::process_blob() tries to if the object
exists when --exclude-promisor-objects is in effect so that it can
return early if the object is missing and it is a promisor object.
I would imagine that we would not want to lazy-fetch the object in
this case.

Thanks.  Will queue.


  reply	other threads:[~2020-07-15 22:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 22:31 [PATCH] upload-pack: do not lazy-fetch "have" objects Jonathan Tan
2020-07-15 22:55 ` Junio C Hamano [this message]
2020-07-16 10:41   ` Jeff King
2020-07-16 17:36     ` Junio C Hamano
2020-07-16 18:09       ` [PATCH v2] " Jonathan Tan
2020-07-20 17:42         ` 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=xmqqpn8wie21.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@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 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.