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
Duy Nguyen <pclouds@gmail.com>
Date
Dec 1, 2015, 12:15 UTC
Message-ID
<CACsJy8CFCu4casNn25b1YPkV==-8kDy3wzYd5uf794R41M0Y9w@mail.gmail.com>
In-Reply-To
<CAGZ79kYY5FbvMpa2vOun7-h4S2cJvZLn67uPGYVbje55R4dFSg@mail.gmail.com>
On Tue, Dec 1, 2015 at 1:47 AM, Stefan Beller <sbeller@google.com> wrote:
Show 29 quoted lines
> On Mon, Nov 30, 2015 at 10:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> +cc Junio, Duy
>>>
>>> So cloning from an arbitrary SHA1 is not a new thing I just came up with,
>>> but has been discussed before[1].
>>>
>>> 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.
>>
>> Yup, I know, but I do not think the above disagrees with you (read
>> again ;-).  It merely says "--branch" option to "clone" is not a
>> good place to add a new "clone at this single commit" mode of
>> operation.
>
> Ok. So maybe a bit of bike shedding time:
>
> How does
>
>     git clone --detached-head <sha1>
maybe
git clone --commit-id <sha1> repo (*)

instead. Detached head is implied, and this way you don't have to disambiguate sha-1 vs refname. And --commit-id can also be added in git-fetch. Actually the git-fetch case is even more interesting, what do we do with refspec..

(*) as usual, we accept committish sha-1, not just comit sha-1, so --commit-id may be confusing..? Or maybe just go with --tag where we accept either tag names, tag sha-1 or commit-sha1

> sound? I would imagine that this would either present you with a fresh clone
> with a detached head at the specified sha1, or if the server doesn't support
> getting a specific sha1, it would error out.
-- 
Duy
Previous: Stefan BellerNext: Junio C Hamano
Message 26 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.