From: Luke Diamand <luke@diamand.org>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: Git Users <git@vger.kernel.org>, Andrew Oakley <andrew@adoakley.name>
Subject: Re: git clone --filter=blob:limit=X interaction with submodules?
Date: Fri, 19 Jun 2020 15:00:23 +0100 [thread overview]
Message-ID: <CAE5ih79Rf3Zygr3mJ30Xew2AWfHs2c67qxjBNBZ=Vpo7raUTeg@mail.gmail.com> (raw)
In-Reply-To: <20200617232018.148877-1-jonathantanmy@google.com>
On Thu, 18 Jun 2020 at 00:20, Jonathan Tan <jonathantanmy@google.com> wrote:
>
> > I noticed that if I do git clone with submodules, using
> > "--filter=blob:limit=whatever" that the filter is applied in the super
> > project, but appears to be ignored in the sub modules.
> >
> > Is that expected behaviour? Or am I just doing it wrong?
> >
> > I'm using git 2.27.0.90.geebb51ba8c.
> >
> > Thanks
> > Luke
>
> Yes, that's expected. The main technical reason is that a lot of the
> subsequent submodule operations may read objects from the submodules,
> and those could trigger on-demand fetches (if the submodules were
> themselves partial clones) - but right now the fetch code is designed to
> run only on one repository.
Would this also explain why I get errors when syncing my superproject:
$ git pull --rebase
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), 844 bytes | 844.00 KiB/s, done.
Resolving deltas: 100% (2/2), completed with 2 local objects.
From ssh://whatever/somerepo
7a9c9e1eeee..3325285b122 master -> origin/master
fatal: git upload-pack: not our ref edcedb543a8b85c659ab7cb507bdb0211fb21bdf
fatal: remote error: upload-pack: not our ref
edcedb543a8b85c659ab7cb507bdb0211fb21bdf
The SSH command failed, please check the server logs for details.
This happens consistently when pulling from a repo that was originally
cloned using --filter. The same repo without the filtering does not
have this problem.
>
> For those who would like to improve this state of affairs, one step in
> the right direction would be to update the fetch and transport code to
> support an arbitrary "struct repository" passed in, and not just operate
> on the_repository.
prev parent reply other threads:[~2020-06-19 14:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 19:14 git clone --filter=blob:limit=X interaction with submodules? Luke Diamand
2020-06-17 23:20 ` Jonathan Tan
2020-06-19 14:00 ` Luke Diamand [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
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 \
--in-reply-to='CAE5ih79Rf3Zygr3mJ30Xew2AWfHs2c67qxjBNBZ=Vpo7raUTeg@mail.gmail.com' \
--to=luke@diamand.org \
--cc=andrew@adoakley.name \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).