title: Merge upstream repository with a fork that replaced directories with submodules
body: <p>Working for a small software company, I recently ran into a number of merge conflicts trying to pull in changes from a 3rd party upstream repository. </p>
  
  <p>The problem is that the upstream repository includes a lot of constantly growing binary assets. </p>
  
  <p>After some deliberation, it was decided that our fork would strip those out and place them into submodules. </p>
  
  <p>As the maintainer of the original repo is against using submodules for the binary assets as well as third party libraries, this creates some difficulties merging changes. </p>
  
  <p>What would be considered the best strategy here? </p>
  
  <p>I've been thinking about adding a .gitattributes file and defining the "ours" merge target for the main repository and then separately pulling in changes for all the submodules. </p>
  
  <p>Is there anything more straightforward? Perhaps a way to make the submodules behave just like the original directories during a merge?</p>
  
  <p>PS: It probably doesn't matter much. But the original repo is on Github while ours is stored on bitbucket. </p>
  
  <p>EDIT: I just realized the maintainer of the original repo has added .gitattributes to .gitignore. This will probably make it harder to apply a merge strategy, won't it?</p>