From: Vincent Fazio <vfazio@xes-inc.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC/PATCH] download/git: support Git LFS
Date: Tue, 17 Dec 2019 14:02:39 -0600 [thread overview]
Message-ID: <20191217200239.GA18361@vfazio1.xes-mad.com> (raw)
In-Reply-To: <20180427125419.787ee93e.john@metanate.com>
> On Fri, 27 Apr 2018 11:17:34 +0100
> John Keeping <john@metanate.com> wrote:
>
> > On Thu, 26 Apr 2018 22:24:40 +0200
> > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> >
> > > On 2018-04-26 18:36 +0100, John Keeping spake thusly:
> > > > Git Large File Storage replaces large files with text pointers in
> > > > the Git repository while storing the contents on a remote server.
> > > > If a repository is using this extension, then git-lfs must be used
> > > > to checkout the large files before the source archive is
> > > > generated.
> > > >
> > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > ---
> > > > Currently this relies on git-lfs being installed on the host
> > > > system and I'm not sure if that's considered acceptable or
> > > > not.
> > >
> > > I think that would be acceptable, but would require a dependency
> > > check, basically, something like
> > >
> > > - support/depenencies/check-host-git.mk :
> > >
> > > ifeq (,$(call suitable-host-package,git,$(GIT) $(if
> > > $(BR2_GIT_NEEDS_LFS).lfs))) $(error You need a git that supports
> > > git-lfs) endif
> > >
> > > - support/depenencies/check-host-git.sh
> > >
> > > #!/bin/sh
> > >
> > > GIT="${1}"
> > > LFS="${2}"
> > >
> > > # If LFS not required, any git is OK
> > > if [ -z "${LFS}" ]; then
> > > echo "${GIT}"
> > > exit 0
> > > fi
> > >
> > > # Test LFS
> > > if ${GIT} help lfs >/dev/null 2>&1; then
> > > # Works!
> > > echo "${GIT}"
> > > exit 0
> > > fi
> > >
> > > exit 1
> > >
> > > Now, all you have, is to find a way to synthetise
> > > BR2_GIT_NEEDS_LFS. ;-)
> >
> > This makes sense, I'll add this check for v2.
>
> Actually, it looks like adding "git-lfs" to DL_TOOLS_DEPENDENCIES works
> and it's a lot simpler. What do you think about handling it that way?
>
>
> Regards,
> John
Can we revive this discussion? I don't see this implemented yet and I know our organization could really use this functionality.
- Vincent
prev parent reply other threads:[~2019-12-17 20:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 17:36 [Buildroot] [RFC/PATCH] download/git: support Git LFS John Keeping
2018-04-26 20:24 ` Yann E. MORIN
2018-04-27 10:17 ` John Keeping
2018-04-27 11:54 ` John Keeping
2019-12-17 20:02 ` Vincent Fazio [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=20191217200239.GA18361@vfazio1.xes-mad.com \
--to=vfazio@xes-inc.com \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox