I don't quite understand this one. "Now you’ll have to create a new commit...". At this point, you haven't yet created a top-level project commit at all.
If the sequence is commit to submodule, push submodule, update top-level module, where is the headache that is unique to submodules here?
If that’s not enough to convince you, you should try branching with this setup. You’ll have to manually branch (and later merge) each of your submodules when you create a new branch. In the past, I have worked with a git repository containing a dozen tightly-coupled submodules for code-sharing with other teams. Needless to say, it didn’t take very long to realize that submodules are not suited for that use case.
Why was submodule better than just using a single repo and multiple remotes in this case? Or put another way, what did you gain by having separate repos if all the repos branch and come back in exactly the same way.
I feel like i can still make a lot of commits on both top-level and submodules but not have a headache, the parallel branching thing seems odd to me.
That sentence intends to illustrate what can happen when you forget to push your submodule commit before commiting on the top-level repository.
Why was submodule better than just using a single repo and multiple remotes in this case?
I'm not sure what you mean with this.
Or put another way, what did you gain by having separate repos if all the repos branch and come back in exactly the same way.
We used submodules because the code in the submodules was shared with another team.
You want to also branch the submodules so as not to break another branch.
Splitting is the same as git-subtree, but doesn't duplicate commits when merging upstream commits to the library, by inverting split, creating commits in the main project corresponding to the upstream commits made to the library.
This results in a beautiful commit history graph: an upstream commit that adds a file to the library, becomes a commit that adds a file to the path to the library in the main project, that gets merged into the main history, which is exactly what you want. It does currently have the same performance problems git-subtree has, but I believe that is not fundamental.
The https://github.com/ingydotnet/git-subrepo addresses all the known concerns of the project owner, project collaborators, and end users. It keeps state in `path/subdir/.gitrepo` which means that git commands like `git mv` just work.
It also has squeaky clean history, which I've documented here: https://github.com/ingydotnet/git-subrepo/blob/master/doc/in...
Feel free to contact me by GitHub, IRC ingy@irc.freenode.net or email ingy@ingy.net.
However, git-subhistory will produce a history better suited for consumption by gitk (and other tools, I assume). I would like to argue though, that these tools should be aware of subrepos instead.
I've been under the impression that using an artifact management tool such as Apache Ivy or Bower provides a more manageable and scalable solution, especially in projects with 20+ developers.
How does the solution proposed by the author compare? Does it compliment a managed artefact based solution?
The advantage of git-subrepo is that your changes are immediately split up between the main project and the subrepo. Eventually, you should also be able to supply a separate commit message for the subrepo change (see "random ideas" section in the article).
