{"thread":{"id":"53703","subject":"git clone --filter=blob:limit=X interaction with submodules?","startedAt":"2020-06-17T19:15:19Z","lastAt":"2020-06-19T14:00:37Z","messageCount":3,"participants":["Luke Diamand","Jonathan Tan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"399991","messageId":"CAE5ih79vZDzKQ1TSNTrL_64XjZH-DJTPqdPH5NMwOrsbaH=n+g@mail.gmail.com","threadId":"53703","inReplyTo":null,"subject":"git clone --filter=blob:limit=X interaction with submodules?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2020-06-17T19:14:59Z","receivedAt":"2020-06-17T19:15:19Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"I noticed that if I do git clone with submodules, using\n\"--filter=blob:limit=whatever\" that the filter is applied in the super\nproject, but appears to be ignored in the sub modules.\n\nIs that expected behaviour? Or am I just doing it wrong?\n\nI'm using git 2.27.0.90.geebb51ba8c.\n\nThanks\nLuke\n"},{"id":"400014","messageId":"20200617232018.148877-1-jonathantanmy@google.com","threadId":"53703","inReplyTo":"CAE5ih79vZDzKQ1TSNTrL_64XjZH-DJTPqdPH5NMwOrsbaH=n+g@mail.gmail.com","subject":"Re: git clone --filter=blob:limit=X interaction with submodules?","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2020-06-17T23:20:18Z","receivedAt":"2020-06-17T23:20:27Z","isPatch":false,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> I noticed that if I do git clone with submodules, using\n> \"--filter=blob:limit=whatever\" that the filter is applied in the super\n> project, but appears to be ignored in the sub modules.\n> \n> Is that expected behaviour? Or am I just doing it wrong?\n> \n> I'm using git 2.27.0.90.geebb51ba8c.\n> \n> Thanks\n> Luke\n\nYes, that's expected. The main technical reason is that a lot of the\nsubsequent submodule operations may read objects from the submodules,\nand those could trigger on-demand fetches (if the submodules were\nthemselves partial clones) - but right now the fetch code is designed to\nrun only on one repository.\n\nFor those who would like to improve this state of affairs, one step in\nthe right direction would be to update the fetch and transport code to\nsupport an arbitrary \"struct repository\" passed in, and not just operate\non the_repository.\n"},{"id":"400122","messageId":"CAE5ih79Rf3Zygr3mJ30Xew2AWfHs2c67qxjBNBZ=Vpo7raUTeg@mail.gmail.com","threadId":"53703","inReplyTo":"20200617232018.148877-1-jonathantanmy@google.com","subject":"Re: git clone --filter=blob:limit=X interaction with submodules?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2020-06-19T14:00:23Z","receivedAt":"2020-06-19T14:00:37Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On Thu, 18 Jun 2020 at 00:20, Jonathan Tan <jonathantanmy@google.com> wrote:\n>\n> > I noticed that if I do git clone with submodules, using\n> > \"--filter=blob:limit=whatever\" that the filter is applied in the super\n> > project, but appears to be ignored in the sub modules.\n> >\n> > Is that expected behaviour? Or am I just doing it wrong?\n> >\n> > I'm using git 2.27.0.90.geebb51ba8c.\n> >\n> > Thanks\n> > Luke\n>\n> Yes, that's expected. The main technical reason is that a lot of the\n> subsequent submodule operations may read objects from the submodules,\n> and those could trigger on-demand fetches (if the submodules were\n> themselves partial clones) - but right now the fetch code is designed to\n> run only on one repository.\n\nWould this also explain why I get errors when syncing my superproject:\n\n$ git pull --rebase\nremote: Enumerating objects: 5, done.\nremote: Counting objects: 100% (5/5), done.\nremote: Compressing objects: 100% (3/3), done.\nremote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0\nReceiving objects: 100% (3/3), 844 bytes | 844.00 KiB/s, done.\nResolving deltas: 100% (2/2), completed with 2 local objects.\nFrom ssh://whatever/somerepo\n   7a9c9e1eeee..3325285b122  master     -> origin/master\nfatal: git upload-pack: not our ref edcedb543a8b85c659ab7cb507bdb0211fb21bdf\nfatal: remote error: upload-pack: not our ref\nedcedb543a8b85c659ab7cb507bdb0211fb21bdf\nThe SSH command failed, please check the server logs for details.\n\nThis happens consistently when pulling from a repo that was originally\ncloned using --filter. The same repo without the filtering does not\nhave this problem.\n\n>\n> For those who would like to improve this state of affairs, one step in\n> the right direction would be to update the fetch and transport code to\n> support an arbitrary \"struct repository\" passed in, and not just operate\n> on the_repository.\n"}]}