From: Stefan Beller <firstname.lastname@example.org>
To: Martin Fick <email@example.com>
Cc: Ben Peart <firstname.lastname@example.org>,
Shawn Pearce <email@example.com>, git <firstname.lastname@example.org>,
Subject: Re: [RFC] Add support for downloading blobs on demand
Date: Tue, 17 Jan 2017 14:23:35 -0800 [thread overview]
Message-ID: <CAGZ79kbWHHOj5x=SqSvUPdXtyYZUqDBnPG+erfZHsUkA8Cv-NA@mail.gmail.com> (raw)
On Tue, Jan 17, 2017 at 2:05 PM, Martin Fick <email@example.com> wrote:
> On Tuesday, January 17, 2017 04:50:13 PM Ben Peart wrote:
>> While large files can be a real problem, our biggest issue
>> today is having a lot (millions!) of source files when
>> any individual developer only needs a small percentage of
>> them. Git with 3+ million local files just doesn't
>> perform well.
> Honestly, this sounds like a problem better dealt with by
> using git subtree or git submodules, have you considered
I cannot speak for subtrees as I have very little knowledge on them.
But there you also have the problem that *someone* has to have a
whole tree? (e.g. the build bot)
submodules however comes with a couple of things attached, both
positive as well as negative points:
* it offers ACLs along the way. ($user may not be allowed to
clone all submodules, but only those related to the work)
* The conceptual understanding of git just got a lot harder.
("Yo dawg, I heard you like git, so I put git repos inside
other git repos"), it is not easy to come up with reasonable
defaults for all usecases, so the everyday user still has to
have some understanding of submodules.
* typical cheap in-tree operations may become very expensive:
-> moving a file from one location to another (in another
submodule) adds overhead, no rename detection.
* We are actively working on submodules, so there is
some momentum going already.
* our experiments with Android show that e.g. fetching (even
if you have all of Android) becomes a lot faster for everyday
usage as only a few repositories change each day). This
comparision was against the repo tool, that we currently
use for Android. I do not know how it would compare against
single repo Git, as having such a large repository seemed
* the support for submodules in Git is already there, though
not polished. The positive side is to have already a good base,
the negative side is to have support current use cases.
next prev parent reply other threads:[~2017-01-17 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 15:52 [RFC] Add support for downloading blobs on demand Ben Peart
2017-01-13 21:07 ` Shawn Pearce
2017-01-17 21:50 ` Ben Peart
2017-01-17 22:05 ` Martin Fick
2017-01-17 22:23 ` Stefan Beller [this message]
2017-01-18 18:27 ` Ben Peart
2017-01-17 18:42 ` Jeff King
2017-01-17 21:50 ` Ben Peart
2017-02-05 14:03 ` Christian Couder
2017-02-07 18:21 ` Ben Peart
2017-02-07 21:56 ` Jakub Narębski
2017-02-08 2:18 ` Ben Peart
2017-02-23 15:39 ` Ben Peart
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).