On Tue, Dec 1, 2015 at 1:47 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Mon, Nov 30, 2015 at 10:11 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Stefan Beller <sbeller@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html