Hi Stefan, On 28.06.2016 19:20, Stefan Beller wrote: >> I have the feeling that “git submodule update --depth 1” is less clever >> than it could be. Here is one example I observed with git 2.0.0: > > 2.9.0 (as "Direct fetching of " is not part of 2.0.0 IIRC) ? Yes, sorry. I had this tested with 2.8.3 at first, then waited for my update to 2.9.0 to reproduce, and garbled the text while adjusting it. > Makes sense! I think the easiest way forward to implement this will be: > > * `git clone` learns a (maybe undocumented internal) option `--get-sha1` > `--branch` looks similar to what we want, but doesn't quite fit as we do not > know, whether we're on a tag or not. The submodule tells us just the > recorded sha1, not the branch/tag. So maybe we'd end up calling it > `--detach-at=<sha1>`, That name makes a lot of sense to me. > that will > -> inspect the ls-remote for the sha1 being there > -> if the sha1 is there (at least once) clone as if --branch <tag> was given Clone but detach, to be consistent. Yes. > -> if not found and the server advertised allowReachableSHA1InWant, > try again inside the clone All of this has to pass through transport and get-pack, right? > * `submodule--helper update-clone` passes the `--get-sha1` to the > clones of the submodules > > * cmd_update() in git-submodule.sh will only checkout submodules and > not try again > to fetch them if `just_cloned` is set as the cloning did the best it could. Sounds like a very reasonable roadmap to me. Do you think there will be someone volunteering to tackle this? Greetings, Martin -- 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