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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 14, 2024, 12:00 UTC
Message-ID: <24f8477b-03c0-5dd5-99c3-7520ce95376d@gmx.de>
In-Reply-To: <s5wed6rg5c6.fsf@catalyst.net.nz>

Hi Phil & Junio,

On Wed, 14 Aug 2024, Phil Sainty wrote:

Show 7 quoted lines

> 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...

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.

Show 12 quoted lines

> > 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?

Show 5 quoted lines

> 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.