Re: How to get a directory filled with v2.6.11?

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> That said, whatever you do you will eventually end up with a series of
> commits that are not related to the "normal" commits in the 2.6.12-rc2+
> chain, and since they don't have a common point, git won't be able to
> merge them for you. Git will be able to _track_ them for you, but at some
> point you'll want to probably try to move them forward to the "rest" of
> the git history.
>
> And I'll warn you that that is not going to be entirely trivial, although
> Junio's "cherrypick" scripts should be useful as a way to automate it at
> least to some degree. This is why it would be so much easier if you could 
> have started with a 2.6.12-rc2 or other "real" commit ;)

I do not think git-cherry would be that useful in this context.
Nobody upstream is merging things into your development trail,
started at the private commit you made based on the 2.6.11 tree.

I was wondering if adding "graft trail" to merge-base command
would help this situation.

    SYNOPSIS
    --------
    'git-merge-base' ( --graft <commit1> <commit2>)* <commit> <commit>

    ...

    OPTIONS
    -------
    <commit>::
            The two heads being merged.

    --graft <commit1> <commit2>::
            Treat as if <commit1> is one of the ancestors of
            <commit2> when computing the commit ancestry chain.
            Can be specified more than once.

Then we could say "--graft v2.6.11 v2.6.12-rc2".

We may want to have a configuration file in .git/ directory (I
think it belongs to .git/objects/ hierarchy, because this is not
per work-tree thing but per project thing) that record this
"graft" relationship.

When we have not-so-stupid [*1*] merge algorithm in place, we
could do even better.  Starting from v2.6.11 tree, we can
rebuild (from BKCVS) the development trail up to v2.6.12-rc2,
which is independent from the current kernel development trail
which started at (a different) v2.6.12-rc2.  Use the former one
as <commit1>, and the latter one as <commit2>, and the "clever"
merge algorithm would be able to follow across the v2.6.12-rc2
discontiguity and trace the development back to v2.6.11.

[Footnote]

*1* <Pine.LNX.4.58.0507052011440.3570@g5.osdl.org>

So if you want to document that the current automatic merge is stupid,
hey, go wild. It _is_ stupid. It's surprisingly effective, but that may be
because of kernel development patterns and may not be true in other
projects.