On Fri, Feb 19, 2016 at 1:13 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Regarding performance, the first fetch should fail quite fast iff the fetch >> fails and then continue with the normal fetch. In case the first fetch works >> fine getting the exact sha1, the fetch should be faster than a default fetch >> as potentially less data needs to be fetched. > > "The fetch should be faster" may not be making a good trade-off > overall--people may have depended on the branches configured to be > fetched to be fetched after this codepath is exercised, but now if > the commit bound to the superproject tree happens to be complete, > even though it is not anchored by any remote tracking ref (hence the > next GC may clobber it), the fetch of other branches will not > happen. > > My knee-jerk reaction is that the order of fallback is probably the > other way around. That is, try "git fetch" as before, check again > if the commit bound to the superproject tree is now complete, and > fallback to fetch that commit with an extra "git fetch". > FWIW, I think the order you suggest here is probably better. It would be lower risk of breaking something since we'd only do something more in this case if the current fetch fails. I've definitely been bit by this before thinking that the sub module would be able to be fetched just fine only to discover that it wasn't able to locate the change. Regards, Jake -- 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