All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul Gortmaker" <paul.gortmaker@windriver.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>,
	Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: linux-yocto@lists.yoctoproject.org, bitbake-devel@lists.openembedded.org
Subject: [PATCH 06/21] bitbake: fetch2/git: allow alt references within download dir
Date: Fri,  2 Apr 2021 13:15:42 -0400	[thread overview]
Message-ID: <20210402171557.981599-7-paul.gortmaker@windriver.com> (raw)
In-Reply-To: <20210402171557.981599-1-paul.gortmaker@windriver.com>

It is no secret that we've needed to formalize some kind of sensible
sharing between git repos with common ancestry.  The opportunity for
sharing the mainline kernel base between linux-yocto and linux-yocto-dev
is the main obvious candidate.

Many of us have long been doing local hacks to pre-populate the
downloads dir and avoid lengthy/large downloads, and some have even
been kind enough to try and get a variant of that upstream[1].

But the problem is that it isn't as simple as adding a new "--reference"
switch to the fetcher and then walking away.  That will result in
non-portable and incompatible use cases with existing work flows.   We
have to put some thought into how we see this fitting into the larger
framework of things and in what ways we want to support use of it.

For example, we know we want relative paths in anything in the download
dir, but "clone --reference" will put an absolute path in the alternates
file by default.  We also don't want the SRC_URI to be containing any
absolute paths either.  We also want (pre)mirror stuff to keep working.

So we set some basic ground rules.  Firstly we don't even expose the
obvious "--reference" argument that some of us are used to at all.  That
is because we are going to have two types of references - the common one
based on objets/info/alternates (this commit) and a pack based one (the
subsequent commit).

We also restrict any references to be peers of the other content in
downloads - no /home/fred/super-SDK/kernel-4.19-rt/ type stuff.  The
idea is that once you factor out the common building blocks of source,
then your kernel (staying with that example) becomes a very small repo.
For example - all of the linux-yocto BSPs (standard and -rt) can be held
in a repo that is only 20-30 megabytes - small enough to attach to email.

Clones via alternates have some limitations - for example there is an
arbitrary limit of six[2] levels of nesting, so a pack reference is
introduced to resolve this subsequently.  However alternaltes make sense
for shared non-static (i.e. WIP repos) endpoints, like stable and -rt.

[1] https://lists.openembedded.org/g/bitbake-devel/topic/77645766
[2] https://github.com/git/git/commit/c2f493a4  # if (depth > 5)

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 .../bitbake-user-manual-fetching.rst          |  6 +++++
 bitbake/lib/bb/fetch2/git.py                  | 24 +++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
index 94f4cf3363f6..12a68accc2c5 100644
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
+++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
@@ -447,6 +447,12 @@ This fetcher supports the following parameters:
    parameter implies no branch and only works when the transfer protocol
    is ``file://``.
 
+-  *"altref":* Enables cloned ``git://`` URLs to use the named peer from
+   the downloads dir as a reference through the standard git alternates
+   file for clone (see ``-reference``) and subseqent operations.  Recipe
+   is responsible (via fetch dependency) for ensuring the reference is
+   populated/cloned prior to being called on to act as a reference.
+
 Here are some example URLs: ::
 
    SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index 6cd5d09b2ded..e742010229c3 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -59,6 +59,12 @@ Supported SRC_URI options are:
    Once cloned, nothing will change, so optimize accordingly.  The default
    is "0", set static=1 when appropriate.
 
+- altref
+   Repository is to use named peer from downloads dir as a reference through
+   the standard git objects/info/alternates file for clone and subseqent
+   operations.  Recipe is responsible (via fetch dependency) for ensuring the
+   reference is populated/cloned prior to being called on to act as a reference.
+
 - usehead
    For local git:// urls to use the current branch HEAD as the revision for use with
    AUTOREV. Implies nobranch.
@@ -165,6 +171,8 @@ class Git(FetchMethod):
 
         ud.static = ud.parm.get("static","0") == "1"
 
+        ud.altref = ud.parm.get("altref","")
+
         ud.dlname = ud.parm.get("dlname","")
 
         # usehead implies nobranch
@@ -380,9 +388,20 @@ class Git(FetchMethod):
 
         repourl = self._get_repo_url(ud)
 
+        refname = ud.altref
+        if refname:
+            alts = os.path.join(ud.clonedir, 'objects', 'info', 'alternates')
+            gitdir = d.getVar("GITDIR") or (d.getVar("DL_DIR") + "/git2")
+            refdir = os.path.join(gitdir, refname)
+            if not os.path.exists(refdir):
+                raise bb.fetch2.FetchError("Unable to find reference %s in %s" % (refname, gitdir))
+
         # If the repo still doesn't exist, fallback to cloning it
         if not os.path.exists(ud.clonedir):
             extcloneargs = d.getVar('GITCLONEARGS_' + ud.names[0]) or d.getVar('GITCLONEARGS') or "--bare --mirror"
+            if refname:
+                extcloneargs += " --reference %s" % refdir
+
             # We do this since git will use a "-l" option automatically for local urls where possible
             if repourl.startswith("file://"):
                 repourl = repourl[7:]
@@ -392,6 +411,11 @@ class Git(FetchMethod):
             progresshandler = GitProgressHandler(d)
             runfetchcmd(clone_cmd, d, log=progresshandler)
 
+            # Fix up reference to be relative for tarball/mirror portability
+            if ud.altref:
+                with open(alts, "w") as f:
+                    f.write("../../%s/objects\n" % ud.altref)
+
             if ud.static:
                 runfetchcmd("%s config --bool --add bitbake.static 1" % ud.basecmd, d, workdir=ud.clonedir)
 
-- 
2.25.1


  parent reply	other threads:[~2021-04-02 17:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02 17:15 [PATCH RFC 00/21] Git repository sharing for kernel (and other) repos Paul Gortmaker
2021-04-02 17:15 ` [PATCH 01/21] bitbake: fetch2/git: allow override of clone args with GITCLONEARGS Paul Gortmaker
2021-04-02 17:15 ` [PATCH 02/21] bitbake: fetch2/git: allow limiting upstream fetch refs to a subset Paul Gortmaker
2021-04-03  7:43   ` Richard Purdie
2021-04-02 17:15 ` [PATCH 03/21] bitbake: fetch2/git: allow optional git download name overrride Paul Gortmaker
2021-04-02 17:15 ` [PATCH 04/21] bitbake: fetch2/git: allow specifying repos as static/unchanging Paul Gortmaker
2021-04-02 17:15 ` [PATCH 05/21] bitbake: fetch2/git: ensure static repos have at least one refs/heads Paul Gortmaker
2021-04-02 17:15 ` Paul Gortmaker [this message]
2021-04-02 17:15 ` [PATCH 07/21] bitbake: fetch2/git: append new altref line if/when SRC_URI changed value Paul Gortmaker
2021-04-02 17:15 ` [PATCH 08/21] bitbake: fetch2/git: allow pack references within download dir Paul Gortmaker
2021-04-02 17:15 ` [PATCH 09/21] bitbake: fetch2/git: use constant names for packs in static repos Paul Gortmaker
2021-04-02 17:15 ` [PATCH 10/21] kernel: add basic boilerplate for fetch-only recipes Paul Gortmaker
2021-04-02 17:15 ` [PATCH 11/21] kernel: add a fetch-only recipe for mainline v5.10 source Paul Gortmaker
2021-04-02 20:13   ` Bruce Ashfield
2021-04-02 17:15 ` [PATCH 12/21] kernel: allow splitting mainline v5.10 source download in two Paul Gortmaker
2021-04-02 17:15 ` [PATCH 13/21] kernel: allow splitting mainline v5.10 source download in three Paul Gortmaker
2021-04-02 17:15 ` [PATCH 14/21] kernel: allow splitting mainline v5.10 source download in four Paul Gortmaker
2021-04-02 17:15 ` [PATCH 15/21] kernel: add recipe for linux-master (mainline latest) Paul Gortmaker
2021-04-02 20:16   ` Bruce Ashfield
2021-04-02 17:15 ` [PATCH 16/21] kernel: add stable fetch recipes for v5.4.x, v5.10.x and v5.12.x Paul Gortmaker
2021-04-02 17:15 ` [PATCH 17/21] kernel: add preempt-rt fetch recipes for v5.4.x, v5.10.x and 5.12.x Paul Gortmaker
2021-04-02 17:15 ` [PATCH 18/21] kernel: make v5.4.x Yocto recipes use shared source Paul Gortmaker
2021-04-02 17:15 ` [PATCH 19/21] kernel: make v5.10.x " Paul Gortmaker
2021-04-02 17:15 ` [PATCH 20/21] kernel: make linux-yocto-dev recipe " Paul Gortmaker
2021-04-02 17:15 ` [PATCH 21/21] kernel: disable (pre)mirror for linux-yocto and linux-yocto-dev Paul Gortmaker
2021-04-02 20:19   ` Bruce Ashfield
2021-04-02 22:14 ` [PATCH RFC 00/21] Git repository sharing for kernel (and other) repos Richard Purdie
2021-04-03  1:44   ` Paul Gortmaker
2021-04-03  8:33     ` 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=20210402171557.981599-7-paul.gortmaker@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=bruce.ashfield@gmail.com \
    --cc=linux-yocto@lists.yoctoproject.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.