Discussion on: Git Submodules Revisited

I have been working on a large multi-year project and had it split into seven or more repositories for each component. Since submodules "sucked" (or did back then), I invented my own dependency management tool.

After about two years I have recently converted it all back into a mono-repository because it's so much less work to maintain:

1. Just use normal git commands.
2. If you update a dependency, check it in as-is.
3. The state of the repository is the state of your dependencies, just git clone to start.
4. You can use normal git tools or GUI's (such as Source Tree) and merge/diff tools.
5. Tools and views on GitHub or similar just work.
6. Reduces engineer drag (you spend less time fiddling with dependencies).

The conversion back to a mono-repository required me to write a fairly complex bash script, mostly using git commands (great way to get more experience in git). I wanted to merge the history for all the repositories into one linear history, including tags (but fortunately only one branch).

I made the script repeatable (it leaves the original repositories alone) so I could check that script into git itself and develop it slowly until the results were correct.

Here's some of it:

    echo "Cherry picking $merge_branch into $splice_branch ..."
    git rev-list --no-merges --reverse $start_splice_branch..$splice_branch | \
    git cherry-pick --stdin -x --allow-empty --strategy=recursive -X theirs

See Stackoverflow - Splice unrelated repositories

Having said that, submodules or something similar may be useful for external dependencies, though having said that every company I have worked for just check in the dependencies into a mono-repository.