git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: problems serving non-bare repos with submodules over http

From
Jacob Keller <jacob.keller@gmail.com>
Date
Apr 21, 2016, 22:42 UTC
Message-ID
<CA+P7+xrHpjaTNfu-spfdVGM9OcksYpATpp9yeO10-YXU9GTePQ@mail.gmail.com>
In-Reply-To
<CAGZ79kYTo+CHPvhV6i0U3xqezhGBSXQs9h+5JL6MRh9oAWXvFg@mail.gmail.com>
On Thu, Apr 21, 2016 at 10:48 AM, Stefan Beller <sbeller@google.com> wrote:
Show 26 quoted lines
> On Thu, Apr 21, 2016 at 10:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> 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

Previous: Stefan Beller
Message 12 of 12 in “problems serving non-bare repos with submodules over http”
  1. Yaroslav HalchenkoApr 20, 2016
  2. Stefan BellerApr 20, 2016
  3. Yaroslav HalchenkoApr 20, 2016
  4. Junio C HamanoApr 20, 2016
  5. Stefan BellerApr 20, 2016
  6. Junio C HamanoApr 20, 2016
  7. Stefan BellerApr 20, 2016
  8. Yaroslav HalchenkoApr 21, 2016
  9. Stefan BellerApr 21, 2016
  10. Junio C HamanoApr 21, 2016
  11. Stefan BellerApr 21, 2016
  12. Jacob KellerApr 21, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.