[laughinghan]

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.

[ingy]

Serendipitously, I've been working on a new Git command called `git-subrepo` for the last 3 months that deals with all these concerns and more. The command became fully usable about a week ago.

The https://github.com/ingydotnet/git-subrepo addresses all the known concerns of the project owner, project collaborators, and end users. It keeps state in `path/subdir/.gitrepo` which means that git commands like `git mv` just work.

It also has squeaky clean history, which I've documented here: https://github.com/ingydotnet/git-subrepo/blob/master/doc/in...

Feel free to contact me by GitHub, IRC [e-mail] or email [e-mail].

[brechtm]

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.