|
|
|
|
|
|
by nwg
4498 days ago
|
|
|
Things get even more exciting when you want to push that submodule commit afterwards to fix things, only to find out that someone sneaked in a commit in the meantime! Now you’ll have to create a new commit on the top-level project to point it to your rebased commit, hah! 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.