On Fri, Jul 17, 2009 at 2:27 AM, Avery Pennarun<apenwarr> wrote: >> 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. > rebase doesn't > have any parameters called a "target." What does git-subtree know > that you don't know? By "rebase target" I mean the mutual relation of git-rebase <newbase> and <upstream> paramaters that define where will be the rebased commits. git-subtree can infer that NewProj contains library up to test-split and that OldProj contains library upto test-split-old. The concept of the whole git-subtee workflow is still blurry to me though, so I will report when I gather more usage statistics. > I don't really understand what you're asking for here. At most I need generic ability to shift merged and rebased repository's or ref's "left" (selecting some directory or file) and "right" (prepending some directory to all paths) before actual operation(s). I.e. the antonym of 'split' but without 'add' committree-joining semantics. This can be implemented with some chaining/plumbing presets. -- Sincerly yours, Andrey. -- 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