Re: problems serving non-bare repos with submodules over http
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 21, 2016, 17:45 UTC
- Message-ID
- <xmqqr3dysvne.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <CAGZ79kYmobvZgAeJv7MNXeFXd+Ahg5mtyagt5m+f7Gpp=Ps4iQ@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 10 quoted lines
> 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".