Oooh.
Yeah, it's a great idea, but likely not practical (or even possible).
git-rebase really wants a linear set of patches to rebase, which you
definitely don't have for that big history. In fact, even if rebase did
the full history rebasing, if later history did a merge of an earlier
thing (ie if the patch-series that you're trying to rebase onto was based
on something that wasn't an "epoch tip", but that was in the middle of
intertwined history), you'd really be screwed.
Also, let's face it, rebasing isn't _that_ fast. So trying to rebase huge
swaths of code would be painful as hell, even if it was a nice linear
series.
But yes, for simpler situations, you could try to switch the problem
around like you suggest.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
