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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Jul 17, 2009 at 3:16 AM, Andrey Smirnov<allter@gmail.com> wrote:
> 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.

The problem is that test-split and test-split-old are completely
unrelated trees that have similar-looking files but no common
ancestry.  All git-subtree knows is exactly that.  It can't simplify
anything (in your case) like you seem to think it can.

git-rebase tries to be cleverer, and starts comparing patches and file
similarities so it can graft one tree onto another, and for
convenience, it throws away redundant commits that do exactly what
some other commit did (basically).  This is actually really messy.  As
soon as you get into that situation, you have nothing but a mess.  My
advice would be to clean up the mess as soon as you can (which
appropriate use of git-subtree + git-rebase can help you do).

Then you'll have actual, valid merge history, and git-subtree will be
able to work smoothly using just that.

>> 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.

I think that if you're having this problem, you should look for a less
ugly solution :)

What I think you're asking for is a way of turning all the commits in
a subdir into a patch stream (which git-subtree split can do,
essentially), but then to add a prefix to all the paths in all the
patches, so that you can then apply those patches on top of some other
repo where the files were in another location.  You can do that, I
guess, but you're not taking advantage of git's convenience.

git-subtree encourages you to think of the files in the subtree as
their own separate project, and you can then merge that separate
project into yours.  That's actually a more accurate model of reality,
I think.

Have fun,

Avery