From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: "Richard Greer" <rg@braneaudio.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH] Change git lfs support to allow for destsuffix being set.
Date: Mon, 3 Oct 2022 23:06:34 +0200 [thread overview]
Message-ID: <20221003230634.529ca225@booty> (raw)
In-Reply-To: <00fa7401-7894-3c86-6b25-3ad62d184260@braneaudio.com>
Hello Richard,
On Mon, 3 Oct 2022 12:58:14 -0500
"Richard Greer" <rg@braneaudio.com> wrote:
> From: Richard Greer <rg@braneaudio.com>
>
> When getting large files with git lfs need to try and recreate the path
> where the repo
> is actually located after the unpack.
>
> If destsuffix or subdir (where subdir is not an absolute path) is set
> then it will not be in
> tmpdir/git.
>
> It looks like the more correct place would be in ud.destdir.
>
> This does not address the issue where it will fail in the unpack if
> subdir is an absolute path
> since it cannot possibly be in the same path as the tmpdir. I have no
> idea as to how to
> deal with that.
Text wrapping seems broken in the text. Not necessarily a big problem,
but not nice to read.
> Signed-off-by: Richard Greer <rg@braneaudio.com>
> ---
> bitbake/lib/bb/fetch2/git.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
> index f0df6fb69b..fa454a1c07 100644
> --- a/bitbake/lib/bb/fetch2/git.py
> +++ b/bitbake/lib/bb/fetch2/git.py
> @@ -421,8 +421,8 @@ class Git(FetchMethod):
> # Only do this if the unpack resulted in a .git/lfs
> directory being
> # created; this only happens if at least one blob
> needed to be
> # downloaded.
> - if os.path.exists(os.path.join(tmpdir, "git", ".git",
> "lfs")):
> - runfetchcmd("tar -cf - lfs | tar -xf - -C %s" %
> ud.clonedir, d, workdir="%s/git/.git" % tmpdir)
> + if os.path.exists(os.path.join(ud.destdir, ".git", "lfs")):
> + runfetchcmd("tar -cf - lfs | tar -xf - -C %s" %
Here wrapping is also wrong, but this one is definitely a problem. You
must not wrap a line in a patch, otherwise it won't apply.
I strongly suggest to use 'git format-patch' + 'git send-email' to send
a patch. Those tools will ensure the patch is not mangled, and it will
apply correctly. More info at
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
Can you please send a v2 with that fixed?
Best regards.
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
parent reply other threads:[~2022-10-03 21:06 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <00fa7401-7894-3c86-6b25-3ad62d184260@braneaudio.com>]
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=20221003230634.529ca225@booty \
--to=luca.ceresoli@bootlin.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=rg@braneaudio.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.