title: What is a good workflow for submodule forks
body: <p>Suppose we have the following repository structure on github:</p>
  
  <pre><code>company:project.git
    \- company:submodule.git
  </code></pre>
  
  <p>A developer in my company forks the company project, making his workspace look like this:</p>
  
  <pre><code>developer:project.git
    \- company:submodule.git
  </code></pre>
  
  <p>This is fine for 90% of the developers since they don't change the submodule library, they only work in the project. Now suppose there's a new feature which requires improvements in the submodule. The developer charged with this converts his workspace to this:</p>
  
  <pre><code>developer:project.git
     \- developer:submodule.git
  </code></pre>
  
  <p>Getting there is not trivial as he needs to replace a submdule with another submodule (to git, the original and the fork of the submodule are two different things).</p>
  
  <p>If this developer works on the library for a bit longer, he commits this structure to his master branch, so his fork on github always uses the forked submodule.</p>
  
  <p>Once he's ready with development, he'll create a pull request. The problem is that when merging the pull request the main repository will look like this:</p>
  
  <pre><code>company:project.git
     \- developer:submodule.git
  </code></pre>
  
  <p>This is problematic as now every developer that tracks the company branch will end up with the developer's submodule.</p>
  
  <p>To workaround the problem, before the developer makes a pull request, his master branch should be moved back to the company:submodule.git - which is just very awkward, especially since locally he'll always still want to work with developer:submodule.git.</p>
  
  <p>We've tried several workflows, and the above issue is the only one where we don't have a good workflow yet.</p>