Thread (1 message) 1 message, 1 author, 2017-02-21

Re: url.<base>.insteadOf vs. submodules

From: Junio C Hamano <hidden>
Date: 2017-02-21 23:59:57

Junio C Hamano [off-list ref] writes:
So I would think it is entirely reasonable if "git submodule init
sub" that is run in the superproject to initialize "sub" writes
something in "sub/.git" to tell that "sub" is used in the context of
that particular toplevel superproject and customize its behavour
accordingly.  Perhaps it may want to add the url.*.insteadOf that is
useful for updating the submodule repository when it does "submodule
init", for example.
Of course, "copying" is usually not very desirable, as it invites
one of the copies to go stale.  An actual implementation may just
say "the name of submodule the superproject uses this as is 'foo'".

That way, if such a configuration exists, Git can first do cd-up to
the root of the working tree, go one level up, verify that it is in
a worktree of its superproject, verify that the root of the working
tree it came from was indeed bound to the submodule called 'foo' and
then do the selective/filtered "config-include" Peff outlined.  That
would allow superproject to move submodules around (as opposed to
recording "this submodule is used at this/path of the superproject"
or "the superproject of this submodule is at ../../that/path"), and
does not penalize repositories that are not used as submodules of
any superproject (because the "cd-up, up, verify and include" won't
be done for them).  As opposed to "I am used as a submodule" bit,
recording the name the superproject uses to call the submodule would
also serve as a sanity check measure.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help