Re: [PATCH 08/15] scalar: implement the `clone` subcommand

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 3, 2021, 17:18 UTC
Message-ID: <xmqq35qlh91x.fsf@gitster.g>
In-Reply-To: <a7c9870a-9af3-bac8-1964-358ecdebe344@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 21 quoted lines

>> Ahh, you do not do "git clone"; you do "git init", set things up,
>> and then "git fetch" and checkout, all manually.
>> 
>> Which is kind of shame.
>> 
>> I wonder if it is a cleaner implementation to give a new option to
>> "git clone" that gives a command sequence (not necessarily have to
>> be implemented as a shell script) that specifies necessary
>> pre-configuration steps to be done before the command starts the
>> transfer step.
>
> I agree that 'git clone' plus maybe some more improvements like
> '--sparse=cone' to set up cone-mode sparse-checkout would be good.
> And also the implementation being contributed here is cleaner if
> we can use 'git clone'.
>
> We are trying to balance a clean upstream implementation with some
> custom things that we still need in our microsoft/git fork to
> handle the integration with the GVFS Protocol (i.e. partial clone
> on Azure Repos). That customization is cleaner to keep here in the
> scalar code instead of adding an option to 'git clone'.

Oh, there is no disagreement on that point, at least in the short term. I was wondering why "clone" subcommand needs a duplicated logic that should be unnecessary, before realizing that this was not implemented as a wrapper to (possibly updated) "clone", and I agree that starting with a looser coupling like this step does is easier to everybody.

"Kind of shame" is just that I wished we had already prepared "git clone" side to accept customization more easily before its various distinct phases (new repository creation, where a custom logic may want to affect the name and location of it and how "git init" is driven, initial "fetch", where a custom logic may want to affect the fetch refspec and its parameters like depths and cones, and initial "checkout") do their things. If we allowed such plug-in of logic to affect how "git clone" worked already, it would have been possible to do "scalar clone" with much less code. It also would allow us to reorganize the "clone --local" hack in a way that is easier to reason about (I think even in today's code, the way I hooked it up can be seen which is quite messy). It may even help folks who want to extend "git clone" to clone a repository recursively its submodules with project-specific customizations (like which ones to clone by default, etc.).

I suspect that learning from the way "scalar clone" is done on top of "init" + "fetch" + "checkout" in this initial series may help us extend "git clone" later to fill such needs.

> If your opinion to switch to 'git clone' is a strong one, then I
> could see us doing that change. I just want you to be aware of the
> hidden reasons for choices like these.

Not at all at this moment.

It is mostly that the way "init" + "fetch" + "checkout" was done in this step reminded me of a much longer-term wish I have had for a while.