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. In order to propagate "--single-branch" thru "--recurse-submodules", I suspect that you would need to teach "clone" a new option that is different from "--branch" that allows you to clone the history starting from the commit recorded in the tree of the superproject in the submodule. That would be orthogonal to "--depth $n", of course, in other words, a top-level "--single-branch --recurse-submodules" clone should trigger the "history reachable from a specified commit" mode of clone in submodules, and if the top-level one specified the "--depth" option, the lower-level ones can limit the depth accordingly. -- 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