title: How to merge nested git repo into parent repo, retaining history?
body: <p>Now I know most git experts will immediately think of <code>git rebase</code>, but I am using the word "rebase" in the more general sense: I have the following structure of my project:</p>
  
  <pre><code>.
  ..
  .git
  tools
  lib
  src
      .git
  build
  </code></pre>
  
  <p>Both <code>.</code> and <code>./src</code> directory are evidently <code>git</code> repositories, and have literally a long history and large number of commits each. The repository in <code>.</code> ignores <code>src</code> directory (which is its own repo).</p>
  
  <p>I have just realized that I would instead want to just have one single repo in <code>.</code> tracking everything including the source files, because frankly, the build system is evolving along with the source code, and has become quite extensive.</p>
  
  <p>My problem is that I don't know how to have this repository retain history that is now part of  the repository in <code>src</code>. Is it even possible? This is what I meant by 'rebasing' - if changes in <code>./src/main.c</code> are tracked by <code>./src/.git</code> across some N commits, then I want to retain these changes and have them be part of the new repository <code>./.git</code>. Same history, rebased file path.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Subtree merging is something else than what I want, from what I gathered on SO. In short, it does much more than what I need. I merely need the content of the old repo, together will <strong>all branches</strong> of development and all commits, tags, etc to look as if they were always part of the parent repo. In essense, the only change is paths to files themselves - where before the child repo tracked <code>./main.c</code>, the new repo will now track <code>./src/main.c</code>, and since as I have heard, <code>git</code> tracks content, not files, then changing file paths like the above and references to these paths, should be rather trivial, correct?</p>