Junio C Hamano <gitster@xxxxxxxxx> 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
