Sounds interesting, however it lacks specifications/documentation.

In particular, I'd like to know what happens with commits that touch paths across subtrees. IMHO, this is the most interesting use case, because otherwise, I'd just extract the commits touching the subdirectory of the subtree with git-log.

Skimming over the source, I don't think git-subtree handles commits across subtrees at all, but I hope I am wrong.

Even if it didn't handle commits across subtrees, I would still find this useful.

I would be ok if this (or an addon) tool detected commits that that spanned subprojects and invited me to split that commit.

IMHO, the correct workflow should be: check in modifications to the library subtree and to the library's client in different commits.

A sane thing to do would be to keep the commit log, but only the changes to the subtree in question.

However, though I am not a bad sh programmer, at some point my brain turned off reading that code.

How is this different from Braid? http://github.com/evilchelu/braid/tree/master

Braid appears (from the readme anyway) to only allow tracking of other repos. This subtree thing allows you to make changes and export those changes back to the appropriate upstream repo.

To use Braid's example with the rails app that is tracking the Rails git repo... if you found a bug in Rails and fixed it, you could then push that change back upstream. (Obviously this is more useful if you have rights to change the upstream repo.)

If Braids supports doing that too, then more power to it!

Interesting approach. I hope this (or something similar to it) is widely adopted and replaces the current submodule situation.

I like it!