Re: Adding nested repository with slash adds files instead of gitlink

[Phil Sainty <phil@catalyst.net.nz>]

Junio C Hamano <gitster@pobox.com> writes:
> Let me make sure I understand the above.  You create a commit to
> contain the change in the submodule and at the same time create a
> new commit to bind the updated submodule commit to superproject tree.

I can imagine this ability also being useful, but it would be an
independent feature from the one initially requested here...


> But I did not get the impression that it is what the original poster
> wants.  My reading of the original thread (this is a resurrection of
> an antient thread dating back to 2018) was that you have a submodule
> at path S, you muck with a file in S/file, and you want to commit in
> the context of the superproject, having the superproject track S/file
> in its history (not just S gitlink).

That's correct.

My common usage was that I would add the entire contents of S, along
with some associated configuration outside of S, and then make a commit
of all of that in the superproject.

The two repos (superproject and submodule S) are then tracking the files
in S independently; so if I was to pull new changes to the submodule
from its own upstream, git commands run from the S directory would not
show any changes vs the state of the submodule repo, whereas commands
run from the superproject would see new changes.

Cloning the superproject repo would produce its version of S, and
without the S/.git directory.


-Phil