git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, stolee@gmail.com
Subject: Re: [PATCH v2] cache-tree: do not lazy-fetch merge tree
Date: Mon, 09 Sep 2019 14:05:53 -0700	[thread overview]
Message-ID: <xmqqef0pi3im.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <xmqqsgp5i6s1.fsf@gitster-ct.c.googlers.com> (Junio C. Hamano's message of "Mon, 09 Sep 2019 12:55:26 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Isn't that what is going on?  I thought I dug up the original that
> introduced the has_object_file() call to this codepath to make sure
> we understand why we make the check (and I expected the person who
> is proposing this change to do the same and record the finding in
> the proposed log message).
>
> I am running out of time today, and will revisit later this week
> (I'll be down for at least two days starting tomorrow, by the way).

Here is what I came up with.

    The cache-tree datastructure is used to speed up the comparison
    between the HEAD and the index, and when the index is updated by
    a cherry-pick (for example), a tree object that would represent
    the paths in the index in a directory is constructed in-core, to
    see if such a tree object exists already in the object store.

    When the lazy-fetch mechanism was introduced, we converted this
    "does the tree exist?" check into an "if it does not, and if we
    lazily cloned, see if the remote has it" call by mistake.  Since
    the whole point of this check is to repair the cache-tree by
    recording an already existing tree object opportunistically, we
    shouldn't even try to fetch one from the remote.

    Pass the OBJECT_INFO_SKIP_FETCH_OBJECT flag to make sure we only
    check for existence in the local object store without triggering the
    lazy fetch mechanism.


  reply	other threads:[~2019-09-09 21:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 19:42 [PATCH] cache-tree: do not lazy-fetch merge tree Jonathan Tan
2019-09-04  1:37 ` Derrick Stolee
2019-09-04 22:35   ` Jonathan Tan
2019-09-04 23:35     ` Junio C Hamano
2019-09-09 19:01 ` [PATCH v2] " Jonathan Tan
2019-09-09 19:55   ` Junio C Hamano
2019-09-09 21:05     ` Junio C Hamano [this message]
2019-09-09 22:21       ` Jeff King
2019-09-10  1:09         ` Junio C Hamano
2019-09-10 18:15       ` Jonathan Tan
2019-09-10 12:49   ` SZEDER Gábor
2019-09-10 18:19     ` Jonathan Tan

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqef0pi3im.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=stolee@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).