On Wed, May 18, 2016 at 5:59 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > The commit from the submodule that is bound to the superproject may > no longer be sitting at the tip of any branch in the submodule. The > hack you are outlining here would not help, and invites "the feature > works some of the time (i.e. the commit happens to be at the tip of > one of the refs) but fails most of the time" bug reports. Sure, that's a reasonable fear. In this case the branches don't move, but if one were concerned about that one could use tags instead. It is quite reasonable to point a submodule to a tag and not expect that to go away. > So I am not enthused, even though at the technical level, I agree > that it is a good "solution" to pretend as if one of the refs were > requested after the fetch-pack discovers the refs advertised by the > upload-pack. It could also lead to allowing "git clone -b $SHA". It's possible to implement this today by manually doing the conversion via git ls-remote. This is a significant streamlining that would interact well with the recent change to submodules to attempt "git fetch origin $SHA1". > I just fear that it is a wrong approach to solve the real issue and > instead make it worse by relieving the pressure from the project and > hosting site to configure their repository to support their users > properly. Unfortunately I don't see the likes of github or bitbucket adding allow-reachable-sha1-in-want any time soon, as it is an expensive operation server-side. This is a significant boost to utility of shallow submodules (a flag for which was just recently added to clone), without requiring any significant changes to repository configuration. - JP -- 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