Re: [PATCH/RFC 1/2] Add 'git subtree' command for tracking history of subtrees separately.

[Andrey Smirnov <allter@gmail.com>]

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.