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 01/21] bitbake: fetch2/git: allow override of clone args with GITCLONEARGS
Date: Fri, 2 Apr 2021 13:15:37 -0400 [thread overview]
Message-ID: <20210402171557.981599-2-paul.gortmaker@windriver.com> (raw)
In-Reply-To: <20210402171557.981599-1-paul.gortmaker@windriver.com>
Currently there is no way to avoid the "--mirror" argument when doing an
initial clone. This is problematic in that there are now a significant
number of repos out there for which we want the content, but creating a
full mirror clone isn't practical or efficient.
The two most common examples are:
1) Repos that have "ingested" another repo with no common ancestors - we
see this in "stable-queue" and "linux-rt-devel" repos[1] which started
as repos of queued format-patch output, but then also added the baseline
so the patches could be obtained "pre-applied" for easier automated testing.
Obviously, ingesting all of the linux history grows a repo by gigabytes.
2) Repos that have gone forward in time in a direction we don't care about,
say for example a flag day event, where everything was rewritten from C into
rust in one massive commit, or where a merge of a giant wad of orthogonal
history and/or binary/proprietary content "pollutes" the repo.
In both cases, we can solve the problem by using "--single-branch"
optionally in conjunction with "--branch <goodstuff>" in order to limit
the cloned content to a specific branch or tag. We will only get
content up to that point, and any commits/ancestors leading up to that
point. The clone is fully functional and without any of the limitatons
imposed by shallow clones.
So, in case #1 we simply choose the branch we want - raw unapplied
content, or applied and tagged (and perhaps signed) - but we aren't
subjected to downloading both branches. In case #2 we simply specify
the last known "good" tag before the upstream went off in a direction
that we don't care about.
Note that default behaviour is unchanged - so this is an opt-in feature
which won't impact any existing recipes. We also leave the door open
for it being URL specific via <name> since we know we have multi repo
SRC_URI in recipes-kernel already.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
bitbake/lib/bb/fetch2/git.py | 3 ++-
documentation/ref-manual/variables.rst | 8 ++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index e3ba80a3f52a..22281e2cfb98 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -345,10 +345,11 @@ class Git(FetchMethod):
# 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"
# We do this since git will use a "-l" option automatically for local urls where possible
if repourl.startswith("file://"):
repourl = repourl[7:]
- clone_cmd = "LANG=C %s clone --bare --mirror %s %s --progress" % (ud.basecmd, shlex.quote(repourl), ud.clonedir)
+ clone_cmd = "LANG=C %s clone %s %s %s --progress" % (ud.basecmd, extcloneargs, shlex.quote(repourl), ud.clonedir)
if ud.proto.lower() != 'file':
bb.fetch2.check_network_access(d, clone_cmd, ud.url)
progresshandler = GitProgressHandler(d)
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 0310429bdcab..cd2b77604e87 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -2649,6 +2649,14 @@ system and gives an overview of their function and contents.
:term:`GDB`
The minimal command and arguments to run the GNU Debugger.
+ :term:`GITCLONEARGS`
+ The arguments used to "git clone" when cloning a repo from an
+ an external server into the local download area. The default is
+ "--bare --mirror". Use of "--bare --single-branch --branch foo"
+ will limit what is cloned/downloaded just to the branch/tag "foo".
+ An URL specific GITCLONEARGS_<name> will take precedence over a
+ recipe wide GITCLONEARGS setting, if both are present.
+
:term:`GITDIR`
The directory in which a local copy of a Git repository is stored
when it is cloned.
--
2.25.1
next prev 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 ` Paul Gortmaker [this message]
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 ` [PATCH 06/21] bitbake: fetch2/git: allow alt references within download dir Paul Gortmaker
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-2-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.