This is better than git-subtree, but it unfortunately still results in an ugly commit history graph. I've actually been working on another alternative to git-subtree: https://github.com/laughinghan/git-subhistory
Splitting is the same as git-subtree, but doesn't duplicate commits when merging upstream commits to the library, by inverting split, creating commits in the main project corresponding to the upstream commits made to the library.
This results in a beautiful commit history graph: an upstream commit that adds a file to the library, becomes a commit that adds a file to the path to the library in the main project, that gets merged into the main history, which is exactly what you want. It does currently have the same performance problems git-subtree has, but I believe that is not fundamental.
Splitting is the same as git-subtree, but doesn't duplicate commits when merging upstream commits to the library, by inverting split, creating commits in the main project corresponding to the upstream commits made to the library.
This results in a beautiful commit history graph: an upstream commit that adds a file to the library, becomes a commit that adds a file to the path to the library in the main project, that gets merged into the main history, which is exactly what you want. It does currently have the same performance problems git-subtree has, but I believe that is not fundamental.