From: Maia Xiao <t-maiaxiao@linux.microsoft.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH] fetch2/git: Check srcrev exists in checkstatus()
Date: Wed, 6 Jul 2022 13:14:06 -0700 (PDT) [thread overview]
Message-ID: <d6f373c-eb88-e765-7973-9d4af6de40ee@linux.microsoft.com> (raw)
In-Reply-To: <970e2ed4c836e291aa9845849c0d3d86b57f849c.camel@linuxfoundation.org>
>> Actually never mind on this first point, assuming that this isn't run on
>> all fetch paths (I didn't check that).
>>
>> But my second comment about the depth is something to consider.
>
> Yes, I'm also remembering comments someone made to me recently that
> many git servers don't support limited depth clones because of the load
> they put on the server.
>
> I appreciate this was moved to a newcomer bug as I think we assumed
> there was a straightforward way to remotely ask "is revision X in the
> repo" but it is looking like that might not be that easy :(
Going off what Bruce said, a potentially "softer" way to do this is to
keep self._lsremote(..) as the True condition, but we additionally try
to fetch the specified srcrev and just log a warning if that didn't
work.
If we feel reluctant about the additional fetch, another thing that we
could still do is to log a warning if the srcrev isn't a tag / at the
top of some branch (i.e., not in the ls-remote). I'm not sure if it is
(un)common enough for that check to make sense, though.
Happy to offer a v2 patch if there is interest in either. Thanks for the
discussion, folks!
~maia
next prev parent reply other threads:[~2022-07-06 20:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-05 17:46 [PATCH] fetch2/git: Check srcrev exists in checkstatus() Maia Xiao
2022-07-05 21:27 ` [bitbake-devel] " Richard Purdie
2022-07-05 22:02 ` Paul Eggleton
2022-07-06 15:12 ` Bruce Ashfield
2022-07-06 15:13 ` Bruce Ashfield
2022-07-06 16:19 ` Richard Purdie
2022-07-06 20:14 ` Maia Xiao [this message]
2022-07-07 16:55 ` Bruce Ashfield
2022-07-07 20:50 ` Richard Purdie
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=d6f373c-eb88-e765-7973-9d4af6de40ee@linux.microsoft.com \
--to=t-maiaxiao@linux.microsoft.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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.