Hi Phil & Junio, On Wed, 14 Aug 2024, Phil Sainty wrote: > 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... FWIW I did not intend to suggest anything to do with submodules. There are too many issues with submodules and I don't think they will ever be resolved, as they simply don't integrate into the original, elegant design of having all Git objects in the same repository. What I had in mind (and which I described only very loosely) was to create a super-project commit that references the modified subdirectory as part of the same project, much like `xdiff/` files are tracked inside git/git. Yes, I papered over the need to create at least one new tree object that is derived from the super-project's root tree object and references the root tree object of the "inner" commit. I did not want to go into too many details about the technical implementation, and chose to use the `xdiff/` example as a way to transport my idea, but apparently I was wrong to believe that it would do a good enough job. In essence, what I would love to have is more along the lines of how Subversion allows you to check out just a subdirectory of the project, and restrict the revision history to that directory in that checkout. This is different from submodules, and also from subtrees, as it would allow to treat `xdiff/` as a stand-alone repository, but also allow to treat it as a tracked subdirectory of the super-project at the same time, both equally-well integrated into the standard Git processes like `git log -G`, `git bisect`, `git rebase`, etc. > > 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. This could be achieved in a very hacky way by moving the `.git` directory of S out of the way, committing, then moving it back, right? > 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. I did indeed have a more integrated thing in mind, where the commits of the super-project that touch S and the commits of S were more connected. Ciao, Johannes > Cloning the superproject repo would produce its version of S, and > without the S/.git directory.
