Re: Shallow submodule efficiency

From: Martin von Gagern <martin.vgagern@gmx.net>
Date: Jun 28, 2016, 19:08 UTC
Message-ID: <2808201e-130a-55a4-a4ee-70f4d2f428f6@gmx.net>
In-Reply-To: <CAGZ79kZQTv=QuuSGeYBQ+J89xQwtMmEsq7rvyFOAfSZfM+0YLA@mail.gmail.com>

Hi Stefan,

On 28.06.2016 19:20, Stefan Beller wrote:

>> I have the feeling that “git submodule update --depth 1” is less clever
>> than it could be. Here is one example I observed with git 2.0.0:
> 
> 2.9.0 (as "Direct fetching of " is not part of 2.0.0 IIRC) ?

Yes, sorry. I had this tested with 2.8.3 at first, then waited for my update to 2.9.0 to reproduce, and garbled the text while adjusting it.

Show 7 quoted lines

> Makes sense! I think the easiest way forward to implement this will be:
> 
> * `git clone` learns a (maybe undocumented internal) option `--get-sha1`
>   `--branch` looks similar to what we want, but doesn't quite fit as we do not
>   know, whether we're on a tag or not. The submodule tells us just the
>   recorded sha1, not the branch/tag. So maybe we'd end up calling it
>   `--detach-at=<sha1>`,

That name makes a lot of sense to me.

>   that will
>   -> inspect the ls-remote for the sha1 being there
>   -> if the sha1 is there (at least once) clone as if --branch <tag> was given

Clone but detach, to be consistent. Yes.

>   -> if not found and the server advertised  allowReachableSHA1InWant,
> try again inside the clone

All of this has to pass through transport and get-pack, right?

Show 6 quoted lines

> * `submodule--helper update-clone` passes the  `--get-sha1` to the
> clones of the submodules
> 
> * cmd_update() in git-submodule.sh will only checkout submodules and
> not try again
>   to fetch them if `just_cloned` is set as the cloning did the best it could.

Sounds like a very reasonable roadmap to me.

Do you think there will be someone volunteering to tackle this?

Greetings,
  Martin