3 ms·

Git's submodule feature definitely has rough edges, however, I think the benefits outweigh the cons. One of the best benefits I see is that submodules make emb

Git's submodule feature definitely has rough edges, however, I think the benefits outweigh the cons. One of the best benefits I see is that submodules make embedding forks more manageble. For example, when you include an open source library in your own project, it's common that you'd want to modify the library in some way. If you commit the modified library into your own project's repository, you'll have a harder time absorbing bug fixes/features from upstream later on. Instead of a simple merge, you'd have to check out the updated library somewhere else and use a diff tool to compare the changes. And, if the library changed much, you may need to find the specific commit that your modification were based off so you can understand how to rebase your modifications. In addition, submodules makes it easier to: contribute bug fixes/patches, share modified open source library across different projects, and identify bugs introduced in updated submodules (since the history is preserved).

alexchamberlain 14y ago
If you want to make changes to the upstream, I suggest adding an extra mirror in between the upstream and the repo you want to add the submodule in. That way, you can maintain your version without worrying about how your other code is affected. Only after it is tested do you then merge it into your other repo.
- buddydvd 14y ago
  The projects I add as submodules are all hosted on Github. For those that require modification, I would fork (mirror) the project, commit the changes to my fork, and add the fork as a submodule to the parent project I'm working on. So, yes, I do add an extra mirror in between but it's really because I lack contributor permission to the main repository. Also, if repository A and B reference repository C as a submodule and I update repository C for A, B would not be affected since submodule references are just commit IDs. There's no need to create two additional mirrors (C-for-A and C-for-B) if that's what you meant.

alexchamberlain 14y ago

If you want to make changes to the upstream, I suggest adding an extra mirror in between the upstream and the repo you want to add the submodule in. That way, you can maintain your version without worrying about how your other code is affected. Only after it is tested do you then merge it into your other repo.

buddydvd 14y ago
The projects I add as submodules are all hosted on Github. For those that require modification, I would fork (mirror) the project, commit the changes to my fork, and add the fork as a submodule to the parent project I'm working on. So, yes, I do add an extra mirror in between but it's really because I lack contributor permission to the main repository. Also, if repository A and B reference repository C as a submodule and I update repository C for A, B would not be affected since submodule references are just commit IDs. There's no need to create two additional mirrors (C-for-A and C-for-B) if that's what you meant.