[apostacy]

This is such a pain point for me.

I would LOVE something between subtrees and submodules.

I have explored this many times, and if I had the ability to write something like this, I would.

I would love it if I could have a child repo that did not require an external remote and could be bundled and stored within a parent repo, unlike a submodule. But I would also like it if it could be more decoupled from the history unlike a subtree.

I can get most of what I want from submodules and subtrees, but not really enough.

It might be possible without even having to change git. Perhaps if there were a way to have branch namespaces of some kind, and I could have a subtree have completely separate history, but have it checked out within the same working tree. Many of my projects that are submodules only make sense within their parent repo, and it is really redundant to have an external repo for them. But I also don't like to have to do expensive surgery to deal with subtrees, and it would be nice to not have it be completely merged.

My dream is to be able to drop a repo inside another repo and have git just treat it as if it were part of the parent repo. And then to be able to bundle the child repo to the parent and push it.

I know that it is mostly possible to do this already, but it is not easy or intuitive.

[Rotareti]

> My dream is to be able to drop a repo inside another repo and have git just treat it as if it were part of the parent repo. And then to be able to bundle the child repo to the parent and push it.

I'm not sure if I understand you right, but I think I made what you describe: https://github.com/feluxe/gitsub

It's a simple wrapper around git, that allows nested git repositories, with almost no overhead.

I use it for a private library (the parent-repo), which itself contains modules (the child-repos) that I open sourced on github. It works fine for my use case. I wrote it, because I found "submodule" and "subtree" too complicated. 'gitsub' is still in alpha.

[apostacy]

Thank you for sharing that! That's really cool!

I'm just very attracted to the idea of bundling repos together. I frequently use git-annex and datalad, and try to keep binaries and helper scripts in different repositories.

[jsmith45]

Well git can most certainly have multiple separate history trees within one repository that are all technically unreleated.

One could even use the existing submodule feature to reference unrelated history in the same repository, but the submodule tooling would want create a seperate .git folder, and duplicate everything, and would want a url to identify the repo, rather than knowing to use the parent repo.

It ought to be possible to modify git submodule to be able to specify that the submodule is actually just all the refs in namespace "blah" of the physically containing repo. Basically you would only need an expanded version of the .git "symlink file" feature that lets you specifify both "gitdir" and a ref namespace to use for all operations. Then poof, you would have self-contained submodules.

You would still have the problem that namespaced refs do not get cloned by default.

You also have some risk of pushing some refs of the parent that have module entries that reference objects only in unpushed refs in a ref namespace, meaning that if somebody cloned the repo, and tried to expand the self-contained submodules, it would discover that the commits are not present. I'd not be surprised if regular submodules also had that limitation. (I've never really used them in a manner where i might modify and commit in the submodule.)

[namibj]

Last I used submodules, I recall hitting that issue. You need to push the submodule first or one can't checkout the parent repo's master on another machine.

[brechtm]

This sounds pretty much what I described in http://www.mos6581.org/git_subtree_alternative. This solution splits your changes between different branches at the time of commit, instead of afterwards like git-subtree does.

While I do present a proof-of-concept implementation using hooks, a proper implementation would require some changes to the git client, I imagine.