Stefan Beller <sbeller@xxxxxxxxxx> writes:
> At the time of cloning you may run
>
> git clone --recursive --reference <other-super-project-location>
> or
> git clone --recursive --reference-if-able <other-super-project-location>
> or
> git clone --recursive
That's an interesting tangent. I never meant "if-able" to be an
end-user visible option [*1*], but now you mention it, I do not see
a reason why "clone --reference-if-able" of the top-level project
cannot be used together with "--recursive".
> Then later when we run
> git submodule update
> we have this option to know if a submodule alternate should be treated
> as optional or required referenced as the existence
> of the superprojects alternate (as a boolean indicator) is not enough of
> an indicator what the user later wants.
A tangent that comes to my mind after reading this is if letting
"if-able" just skip (with or without warning) and forget about it
once a clone is made is what we really want.
Suppose the "other-super-project-location" repository did not have a
clone of a submodule when you create a new clone of the superproject
using it as a reference. The submodule will be made a full clone,
but after that happens, other-super-project-location can get
interested in the submodule and can acquire its own clone.
At that point, our clone of the submodule _could_ add the submodule
in the other-super-project-location as its alternate and lose the
duplicate objects that it could borrow from there by repacking, but
the suggested "clone with if-able, and forget about it after a clone
is made" would not allow us to do this. I do not know if a
real-world use of submodules want the ability to do so, or it is
unnecessary. I suspect with the recording of "you were told that
borrowing from the same location as the superproject is OK", this
becomes easily doable (i.e. subsequent "submodule update" can realize
that the submodule does not have alternates but it could borrow from
the submodule in the other-super-project-location).
[Footnote]
*1* Rather, I meant: clone has a very intimate knowledge on what and
what cannot be borrowed from and it is not just "is there a
directory?", so "git submodule update --init" is not in a good
position to decide if it wants to add --reference to the
invocation of "git clone" it makes internally, and introducing
an "if-able" variant to "clone" is one way to relieve it from
having to make that decision.
I could have suggested an alternative: because the submodule
machinery is gettting moved to C the "update --init" code that
drives the internal invocation of "git clone" could share the
the logic in "git clone --reference" that determines if a local
repository can be used as an alternate by small refactoring of
builtin/clone.c::add_one_reference().
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html