On Thu, Jul 16, 2009 at 6:09 PM, Andrey Smirnov<allter@xxxxxxxxx> wrote: > On Thu, Jul 16, 2009 at 10:34 PM, Avery Pennarun<apenwarr> wrote: >> I don't think that's a good idea. git-subtree is completely separate >> from rebasing, and doesn't deal with patches at all. Maybe there >> should be some kind of "force-update" option that does what "git >> subtree add" does, but wiping out everything in the subtree before it >> starts. That would have simplified the above commands a bit. > > The only thing that links git-subtree with git-rebase is the fact, that > git-subtree "knows" the target commit for rebases dealing with subtrees. > So if one knows commit of a subtree that he wishes to see in superproject > (in my case "test-split") he could issue: > git subtree rebase --prefix=lib OldProject test-split > > Though simple: > git rebase --onto OldProject test-split-old test-split > worked for me, I think this was a lucky coincidence because of simplicity > of my library commits. I don't really understand what you're asking for here. rebase doesn't have any parameters called a "target." What does git-subtree know that you don't know? Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html