Derrick Stolee <stolee@xxxxxxxxx> writes: >> 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.
