Linus Torvalds <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]>
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
