git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

From
Jens Lehmann <jens.lehmann@web.de>
Date
Nov 16, 2015, 18:59 UTC
Message-ID
<564A279C.6000802@web.de>
In-Reply-To
<CAGZ79kaUZ08GXZjKtYNmRYOCQ0EQpsGd8+6PYFDU1LxYLw818g@mail.gmail.com>
Am 14.11.2015 um 01:10 schrieb Stefan Beller:
Show 17 quoted lines
> On Fri, Nov 13, 2015 at 3:41 PM, Jeff King <peff@peff.net> wrote:
>> On Fri, Nov 13, 2015 at 06:38:07PM -0500, Jeff King wrote:
>>
>>> On Fri, Nov 13, 2015 at 03:16:01PM -0800, Stefan Beller wrote:
>>>
>>>> Junio wrote on Oct 09, 2014:
>>>>> This is so non-standard a thing to do that I doubt it is worth
>>>>> supporting with "git clone".  "git clone --branch", which is about
>>>> "> I want to follow that particular branch", would not mesh well with
>>>>> "I want to see the history that leads to this exact commit", either.
>>>>> You would not know which branch(es) is that exact commit is on in
>>>>> the first place.
>>>>
>>>> I disagree with this. This is the *exact* thing you actually want to do when
>>>> dealing with submodules. When fetching/cloning for a submodule, you want
>>>> to obtain the exact sha1, instead of a branch (which happens to be supported
>>>> too, but is not the original use case with submodules.)

Yes, being able to fetch certain sha1s makes lots of sense for submodules (this has been discussed some time ago at a GitTogether). But - apart from the extra network load - it's rather helpful to get all the submodule branches too (though that could be limited to the branches the sha1 is on).

Show 12 quoted lines
>>> I think this is already implemented in 68ee628 (upload-pack: optionally
>>> allow fetching reachable sha1, 2015-05-21), isn't it?
>>
>> Note that this just implements the server side. I think to use this with
>> submodules right now, you'd have to manually "git init && git fetch" in
>> the submodule. It might make sense to teach clone to handle this, to
>> avoid the submodule code duplicating what the clone code does.
>
> Yes I want to add it to clone, as that is a prerequisite for making
> git clone --recursive --depth 1 to work as you'd expect. (such that
> the submodule can be cloned&checkout instead of rewriting that to be
> init&fetch.
Cool, that should help recursive fetch too.
Show 7 quoted lines
> Thanks for pointing out that we already have some kind of server support.
>
> I wonder if we should add an additional way to make fetching only some
> sha1s possible. ("I don't want users to fetch any sha1, but only those
> where superprojects point{ed} to", even if you force push a superproject,
> you want to want to only allow fetching all sha1s which exist in the current
> superprojects branch.)

Me thinks the restrictions for sha1-fetching could come from the branches these sha1s are found in the upstream submodule: if the client is allowed to fetch a branch, it should be able to fetch any sha1 on that branch.

Show 10 quoted lines
> Maybe our emails crossed, but in the other mail I pointed out we could use
> some sort of hidden ref (refs/superprojects/*) for that, which are
> allowed to mark
> any sort of sha1, which are allowed in the superproject/submodule context
> to be fetched.
>
> So whenever you push to a superproject (a project that has a gitlink),
> we would need to check serverside if that submodule is at us and mark the
> correct sha1s in the submodule. Then you can disallow fetching most of the sha1s
> but still could have a correctly working submodule update mechanism.

And what happens if the submodule isn't at us? Involving the serverside of a superproject in submodule fetching sounds wrong to me. Me thinks that the upstream of the submodule should always control if a sha1 is allowed to be fetched. Or did I understand you wrong?

Previous: Stefan BellerNext: Stefan Beller
Message 10 of 35 in “add test to demonstrate that shallow recursive clones fail”
  1. add test to demonstrate that shallow recursive clones faillarsxschneider@gmail.com, Nov 12, 2015
  2. Stefan BellerNov 12, 2015
  3. Lars SchneiderNov 15, 2015
  4. Jeff KingNov 13, 2015
  5. Stefan BellerNov 13, 2015
  6. Stefan BellerNov 13, 2015
  7. Jeff KingNov 13, 2015
  8. Jeff KingNov 13, 2015
  9. Stefan BellerNov 14, 2015
  10. Jens LehmannNov 16, 2015
  11. Stefan BellerNov 16, 2015
  12. Jens LehmannNov 16, 2015
  13. Stefan BellerNov 16, 2015
  14. Jens LehmannNov 17, 2015
  15. Stefan BellerNov 17, 2015
  16. Jens LehmannNov 17, 2015
  17. Stefan BellerNov 17, 2015
  18. Jens LehmannNov 17, 2015
  19. Duy NguyenNov 17, 2015
  20. Jeff KingNov 17, 2015
  21. Duy NguyenNov 18, 2015
  22. Jeff KingNov 18, 2015
  23. Stefan BellerNov 18, 2015
  24. Junio C HamanoNov 30, 2015
  25. Stefan BellerDec 1, 2015
  26. Duy NguyenDec 1, 2015
  27. Junio C HamanoDec 1, 2015
  28. Junio C HamanoDec 1, 2015
  29. Stefan BellerDec 3, 2015
  30. Junio C HamanoDec 4, 2015
  31. Junio C HamanoDec 4, 2015
  32. Duy NguyenDec 4, 2015
  33. Lars SchneiderNov 15, 2015
  34. Jeff KingNov 17, 2015
  35. Jeff KingNov 19, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.