Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> HEAD is allowed by the protocol spec and would happen, if HEAD points at a >> ref, that this user cannot see (due to ACLs for example). > > A more typical example would be if the ref simply doesn't exist (i.e., > is a branch yet to be born). Indeed this is interesting. At first glance I thought this was about underlying "git clone" failing to grab things from a repository with unborn HEAD, but that part works perfectly OK. And if this failed clone were a full-repository clone that tried to grab even HEAD, then it is likely that we got the tip we need to populate the submodule's working tree (or the remote is useless for that in the first place). So the "allow to try even harder" is probably a good direction to go in. >> # is not reachable from a ref. >> is_tip_reachable "$sm_path" "$sha1" || >> fetch_in_submodule "$sm_path" $depth || > > Is keeping the '||' at the end of this line intended? Good question. It used to be guard1 || action1 || die guard2 || action2 || die Even after a successful exit from "action1", the code used to try the second attempt, and the patch is removing the first die, making the whole thing into guard1 || action1 || guard2 || action2 || die which suggests a grave regression, doesn't it? "action1" (a whole repository fetch) may not pull down the needed commit even the fetch operation itself may succeed, in which case "guard2" notices that the tip is still not here and "action2" (an exact SHA-1 fetch) tries to pull down the exact thing as the last resort. So it probably should be more like guard1 || action1 || warn guard2 || action2 || die so that no matter what the outcome of the action1 is, the second set gets executed.
