From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>,
git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] partial-clone: add a partial-clone test case
Date: Tue, 15 Mar 2022 17:00:02 +0530 [thread overview]
Message-ID: <20220315113002.61748-1-chakrabortyabhradeep79@gmail.com> (raw)
In-Reply-To: <xmqqa6dsnpj9.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> wrote:
> I found it quite a roundabout way to look into trace to see if
> a "fetch" was run to determine if we are doing the right thing.
>
> Regardless of whatever mechanism is used to lazily fetch objects
> that have become necessary from the promisor remotes, what we want
> to ensure is that the blob object HEAD:new-file.txt is still missing
> in our object store after running "log --follow", isn't it? In a
> future version of "git", our on-demand lazy fetch mechanism may not
> even invoke "git fetch" under the hood, after all.
>
> Don't we have a more direct way to ask "does this object exist in
> our object store, or is it merely left as a promise?" without
> triggering a lazy fetching that we can use in this test? I think
> such a direct approach is what we want to use in this test.
I did think of other ways to detect the downloading before. Initially I
thought of using grep functionality to see if any download related
messages are printed or not. But I found that `git log` doesn't print
any download related messages (e.g. like "enumerating ...."). So, I
dropped that idea.
The next idea that came into my mind was to detect if the previous file
(the file from where the new file is renamed) is still missing ( you're
suggesting the same approach). But the problem I faced with this apprach
is I didn't find a way to detect if the file is missing.
I tried to use `git rev-list --objects --missing=print` with `HEAD` and
first commit hash. But in both cases, I didn't found a missing `[?]` sign
before ` <blob-hash-ID> file.txt`. That means, both blob objects ( or I
think the same blob object) exists in the local repo.
Most probably, this is because the content of these two files are same.
Blob object is never modified. So, as far as I think, both base trees ( one
which is pointed by the initial commit and other which is pointed by the latest
commit) is pointing to the same blob object. As a result, the file is not
missing. ( I am not sure if git really does it as I said; sorry if I am
wrong here)
That's why I asked Derrick to help me detecting the download and he
suggested me this. It is true that this is not ideal (use of `fetch` may
change later). But this was the only option that I can go with.
If you find another/better way or if you think I tried to use `git rev-list
...` in the wrong way - please tell me. I would be very happy.
Thanks :)
next prev parent reply other threads:[~2022-03-15 11:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 17:39 [PATCH] partial-clone: add a partial-clone test case Abhradeep Chakraborty via GitGitGadget
2022-03-13 19:41 ` Junio C Hamano
2022-03-14 15:46 ` Abhradeep Chakraborty
2022-03-14 16:25 ` Derrick Stolee
2022-03-14 21:42 ` Junio C Hamano
2022-03-15 8:20 ` Abhradeep Chakraborty
2022-03-14 21:35 ` Junio C Hamano
2022-03-14 16:24 ` Derrick Stolee
2022-03-14 22:21 ` Junio C Hamano
2022-03-15 11:30 ` Abhradeep Chakraborty [this message]
2022-03-15 12:57 ` Derrick Stolee
2022-03-15 15:15 ` Abhradeep Chakraborty
2022-03-15 16:13 ` Junio C Hamano
2022-03-16 8:06 ` Abhradeep Chakraborty
2022-03-16 9:46 ` [PATCH v2] " Abhradeep Chakraborty via GitGitGadget
2022-03-21 15:26 ` Derrick Stolee
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=20220315113002.61748-1-chakrabortyabhradeep79@gmail.com \
--to=chakrabortyabhradeep79@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).