On Thu, Apr 21, 2016 at 10:48 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Thu, Apr 21, 2016 at 10:45 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Stefan Beller <sbeller@xxxxxxxxxx> writes: >> >>> In case of non bare: >>> >>> Get the repo and all its submodules from the specified remote. >>> (As the submodule is right there, that's the best guess to get it from, >>> no need to get it from somewhere else. The submodule at the remote >>> is the closest match you can get for replicating the superproject with >>> its submodules.) >>> >>> This way is heavy underutilized as it wasn't exercised as often I would >>> guess, >> >> My guess is somewhat different. It is not used because the right >> semantics for such a use case hasn't been defined yet (in other >> words, what you suggested is _wrong_ as is). You need to remember >> that a particular clone may not be interested in all submodules, and >> it is far from "the closest match". > > Yes, when that clone doesn't have some submodules, we can still fall back > on the .gitmodules file. > > If you have a submodule chances are, you are interested in it and modified it. > So the highest chance to get your changes is from your remote, no? > -- I agree with Stefan. I think that if I clone from my local non-bare repository that may have work done inside the submodule it would be best if the clone could grab the submodules directly from here and get this work which might not yet be in the "real" remote yet. The case could be made that you don't want to do this, I suppose.. Generally I think since we're already connected to this remote we know we can access it, and getting submodules from here means we know it will work, and give us the actual sha1 that the clone is using. If we use .gitmodules, we'll possibly get a module that doesn't have the commit, and the current gitmodules url might not even work anymore. That is, I don't really understand any downside to Stefan's proposal,and I see a bunch of upside. Thanks, 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