Interesting. This will indeed result in a more linear history, but I don't agree that the commits from the external repo should be absorbed into the main project's history, just as the subtree changes should not be present in new commits made in the main project (hence git-subrepo). So, no, git-subhistory is not exactly what I want :)
However, git-subhistory will produce a history better suited for consumption by gitk (and other tools, I assume). I would like to argue though, that these tools should be aware of subrepos instead.
However, git-subhistory will produce a history better suited for consumption by gitk (and other tools, I assume). I would like to argue though, that these tools should be aware of subrepos instead.