Question

When using git submodules, what is the preferred way of doing customizations? Should I…

• fork the project and track the fork
• attempt to override the default behavior
• make the changes locally

If none of these makes sense, then what does?

Answer 1

I’m not quite sure if your question implies that all the projects you want to include are already git projects or if they are currently svn, mercurial, non-version controlled. If it’s the latter, it would have to be a case-by-case answer.

Most likely, the projects you want to include and customize are already on, say, github and then you should definitely fork through github and use those forks as submodules. Any customization should be checked in and pushed to github.

It could be trickier if the projects you want to include are somewhere else (or are based on svn, mercurial, etc.). One way is to fork the projects locally and then set up cron-jobs to push any incoming changes to github. That is, create github mirrors. To be in total control of both merging and upgrading you might have to fork those mirrors and include those forks as submodules in your project, checking in local customizations and pushing them to the fork of the mirror.

Alternative #3, fork projects and do local check-ins only, could be used in situations where you don’t have the above options and what you are creating is not really intended to be easily distributed.

Monkey patching (alternative #2 on your list) should be an alternative left to situations where you don’t want a project to become dependent on you keeping a customized fork up to date with upstream changes.