Git submodule alternative?

Question

I have a couple of working trees with some dependences. AFAIK, git submodule would enforce the following:

• have a copy of each working tree (slave) in a subdirectory of each working tree using it (master)
• the master repository duplicates all the information from slaves

I don't mind the repos getting bigger, but having the copies is quite unacceptable for me. It would force me to reorganize all the projects, so that the copy would get linked. Moreover, editing of a wrong file could easily happen leading to confusion.

I've got another idea:

• Each master stores a list of all its slaves.
• No other information in the master is required.
• With each commit in master, a "snapshot-commit" in the slave gets created.
• The "snapshot-commit" is a snapshot of the current state of the working tree, it ignores the current state of the index (I'm already using "snapshot-commits" before throwing away some uncommited changes).
• The "snapshot-commits" get collected in a branch whose name is derived from the master's name. The commit message contains the hash of the master commit. (IMHO, this is better than flooding by thousands of tags.)
• A checkout works as usual, unless recursion into slaves is required.

The only problems I can see are the following:

• The commits in the slaves will accumulate, and never get deleted even when the master commits no longer exist.
• Commits in the master are not self-containing, you could delete a commit referred in the master. But I see no chance it could happen by accident, so I can live with it.
• I can't imagine, how other git command could support this. But again, I can live with it.

I'm asking if somebody already implemented it (or if it's a bad idea).

Answer 1

I think this is a bad idea because it's strange and it will take you off the supported path for many things.

First a clarification: When using submodules, the 'master' (referencing) repo does not get appreciably bigger. It stores only a repository reference (URL, probably) and a commit ID. But that doesn't seem to be the sticking point here.

When dealing with a problem like this there are three basically 3 paths you can go down:

1. Put everything in a single repository. Have you convinced yourself 10 times that you really need to separate things out? Remember that you can start in one repo and split things out later. Also remember that git merges actually work, so developer contention isn't that much of an issue.

2. Use some external package management system. Git is NOT, and doesn't pretend to be, a package manager. Odds are good that the platform you're using has a package manager that supports more complex dependency situations. Maven, rubygems, npm, nuget... there are lots of them.

3. Use submodules 'mounted' in subdirectories.

Basically, submodules should be your last choice when dealing with your own code. They're great for dealing with third party libraries, but end up being a royal pain for your own code. Add on top of that the complicated solution you're proposing, and it just won't be very fun to work in.

Answer 2

I am not sure I am following you since a parent repo (your "master") only store a reference to the tight SHA1 of a submodule (the sub-repo checked out within the parent repo).
The size of the parent repo isn't affected at all.

The subtree merge strategy (better managed though git subtree) would increase the size of the parent repo, but that (subtree merge) isn't what you are talking about.

The other alternative to submodule would be git-slave (gits), which is a bit like you want to implement.