All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: "bitbake-devel@lists.openembedded.org"
	<bitbake-devel@lists.openembedded.org>,
	"xe-linux-external (Internal Group)"
	<xe-linux-external@cisco.com>
Subject: Re: [bitbake-devel] [PATCH] fetch/git: add reference option
Date: Fri, 26 Jun 2026 20:34:49 +0000	[thread overview]
Message-ID: <aj7iaF9eu-G9w0Wx@goliath> (raw)
In-Reply-To: <CADkTA4MVj9Ja806ja_0y7zo2J4sFdOvvUbm2_aR3tcQig4brvA@mail.gmail.com>

On Fri, Jun 26, 2026 at 03:56:02PM -0400, Bruce Ashfield wrote:
> On Fri, Jun 26, 2026 at 3:10 PM Daniel Walker via lists.openembedded.org
> <danielwa=cisco.com@lists.openembedded.org> wrote:
> 
> > Adds a option to the git fetcher which can be used to specify a local
> > reference for a given SRC_URI. Which is then fed into the clone command
> > as "--reference-if-able" which make the option fault tolerant if the
> > directory doesn't exist.
> >
> 
> We tried this in the past (maybe 10 years ago now) to chunk the
> kernel into different sets of blobs and do a set of references for
> optimal sharing, repacking, etc.
> 
> In the end, it was discarded as unnecessary complexity.
> 
> I'm still of the opinion that is the case. What problem is this solving
> that justifies the complexity ?
> 
> the patch doesn't show a real world use case, what the SRC_URI
> would look like, where the referenced clone would be, what would
> happen if the referenced repository was somehow cleaned, or
> any number of different interactions (what happens if shallow is
> specified, etc, etc).
> 

At Cisco we have settings which modify the SRC_URI to become the local repo.

For example,

KERNEL_REPO:pn-linux-cisco = "git:///local/git/cache/;protocol=file"

This works to use a local cache of the repo, but it messes up the state cache so
objects can't be used by others.

If we use "--reference-if-able" then the git host and location remains the same, but the
local copy can speed up the clone.

For down stream users, like Cisco, who work in a complex environment it's
helpful to have flexibility.

The reference is not harmful that I know of, it's only used if it can be used.

Daniel

      reply	other threads:[~2026-06-26 20:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 19:10 [PATCH] fetch/git: add reference option Daniel Walker
2026-06-26 19:56 ` [bitbake-devel] " Bruce Ashfield
2026-06-26 20:34   ` Daniel Walker (danielwa) [this message]

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=aj7iaF9eu-G9w0Wx@goliath \
    --to=danielwa@cisco.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=bruce.ashfield@gmail.com \
    --cc=xe-linux-external@cisco.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.