 <p>If you want to maintain your own version of LibraryB you have a few options:</p> <ul> <li><p>You can make LibraryB inherent part of your project: just remove or comment out <code>[remote "LibraryB"]</code> section in the config file, and make changes to LibraryB inside your project.</p> <p>The disadvantage is that it would be harder to send patches for canonical (third-party) version of LibraryB</p></li> <li><p>You can continue using 'subtree' merge, but not from the canonical version of LibraryB, but from your own clone (fork) of this library. You would change remote.LibraryB.url to point to your local version, and your local version would be clone of original LibraryB. Note that you should merge your own branch, and not remote-tracking branch of canonical LibraryB.</p> <p>The disadvantage is that you have to maintain separate clone, and to remember that your own changes (well, at least those generic) to LibraryB have to be made in the fork of LibraryB, and not directly inside ProjectA.</p></li> <li><p>You might want to move from 'subtree' merge which interweaves history of ProjectA and LibraryB, to having more separation that can be achieved using <a href="http://git-scm.com/docs/git-submodule" rel="nofollow noreferrer" title="git-submodule(1)">submodule</a> (<a href="http://git.or.cz/gitwiki/GitSubmoduleTutorial" rel="nofollow noreferrer" title="Git Submodule Tutorial at Git wiki">tutorial</a>). In this case you would have separate repository (fork) of LibraryB, but it would be inside working area of ProjectA; the commit in ProjectA would have instead of having tree of LibraryB as subtree, pointer to commit in LibraryB repository. Then if you do not want to follow LibraryB development, it would be enough to simply not use 'git submodule update' (and perhaps just in case comment out or remove link to canonical version of LibraryB).</p> <p>This has the advantage of making it easy to send your improvements to canonical LibraryB, and the advantage that you make changes inside working area of ProjectA. It has disadvantage of having to learn slightly different workflow.</p> <p>Additionally there is also an issue of how to go from 'subtree' merge to submodules. You can either:</p> <ul> <li>Move from subtree merge to submodule by creating git repository in the subproject subtree in superproject working repository (i.e. "git init" inside appropriate subdirectory + appropriate "git submodule init" etc.). This means that you would have 'subtree' up to some point of history, and submodule later.</li> <li>Rewrite history using <a href="http://git-scm.com/docs/git-filter-branch" rel="nofollow noreferrer" title="git-filter-branch(1)">git filter-branch</a> to replace subtree merge by submodule. This has the disadvantage of rewriting history (big no if somebody based his/her work on current history), and advantage of 'clean start'. Or you can wait a bit for "git submodule split" (<a href="http://thread.gmane.org/gmane.comp.version-control.git/109667" rel="nofollow noreferrer" title="[RFC] What&#39;s the best UI for &#39;git submodule split&#39;?">thread on git mailing list</a>) to make it into git...<br> <em>Unfortunately <a href="http://www.ishlif.org/blog/linux/splitting-a-git-repository/" rel="nofollow noreferrer">Splitting a git repository</a> blog posts returns "host not found"</em></li> </ul></li> </ul> <p>I hope that this version solve your problem.</p> <p><strong><em>Disclaimer:</em></strong> <em>I have used neither subtree merge, nor submodules, nor git-filter-branch personally.</em></p>