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 17, 2015, 20:39 UTC
Message-ID
<564B9091.7070902@web.de>
In-Reply-To
<CAGZ79kZGdOCzJ5V-RZcBbZE09HsSUQrypHaFT-N8wks7NA=21Q@mail.gmail.com>
Am 17.11.2015 um 21:04 schrieb Stefan Beller:
Show 8 quoted lines
> On Tue, Nov 17, 2015 at 11:46 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>
>> But for quite some time you'll have older servers out there that
>> don't support fetching a single sha1 or aren't configured to do so.
>
> Only when talking about the open source side. If you have all the
> submodules/superprojects on your companies mirror, you can control
> the git installations there.

Sure. But that doesn't mean we should make life harder for the open source side, no? We'll have to support both for quite some time.

Show 15 quoted lines
>> Wouldn't it be better to give the user an appropriate warning and
>> fall back to cloning everything for those submodules while using the
>> optimized new method for all others and the superproject? Otherwise
>> you won't be able to limit the depth if only a single submodule
>> server doesn't support fetching a single sha1.
>>
>
> I think warnings are fine, but no fallbacks. The warning could look like:
>
>      Server for submodule <foo> doesn't support fetching by sha1.
>      Fetch again without depth argument.
>
> and keep going with the other submodules. This would allow the user
> to make an informed decision if they want to have the fallback solution
> (which requires more band width, disk space)

No, this is a regression. This worked before but now some submodules are missing from the clone. And if that happens inside a Jenkins script I doubt that Jenkins can make an informed decision, that job will simply fail.

> On the other hand, that's what people do today, so it's not that bad either,
> so I guess falling bad would work too.

Not that bad? I don't see any other sane way. Don't break formerly working use cases without a very good reason. Fall back to what we did before (even if it is suboptimal) and only then use the new optimized (and admittedly better) feature when it is available.

Previous: Stefan BellerNext: Stefan Beller
Message 16 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.