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.) I think this is already implemented in 68ee628 (upload-pack: optionally allow fetching reachable sha1, 2015-05-21), isn't it? > If the server contains at least one superproject/submodule, there is a legit > use case for fetching an exact sha1, which isn't a tip of a branch, but may > be in any branch or even in no branch at all. The patch above doesn't handle "no branch at all", but I'm not sure if we want to (it violates git's usual access model; moreover, a git repository does not necessarily have all ancestors of an unreachable object, though these days it usually does). -Peff -- 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