No, you really really cannot do that.
If the _tree_ you are tracking is itself rebasing (not just your own
tree), then you cannot and absolutely SHOULD NOT use rebase (not directly,
and not with "git pull --rebase".
Why?
Let's look at what happens. Let's say that your history looks like
... -> A -> B -> C -> a -> b -> c
where the upper-case letters are from the tree you track, and the
lower-case letters are the commits you added yourself.
Now, let's say that the tree you track gets rebased, and in the process
'B' is removed (because it turns out it was buggy), and A and C get
modified. What happens?
You now have
... -> A -> B -> C -> a -> b -> c <- your branch
\
other stuff -> A' -> C' <- newly rebased branch
(where "other stuff" is whatever the remote branch was rebased on top
of) and when you now try to rebase your stuff on top of the newly rebased
branch, you are going to end up trying to rebase all the _old_ commits
that weren't even yours (ie it's going to try to rebase A, B and C too!)
And that's not what you want! It will potentially not only generate lots
of conflicts (because A' and A aren't the same, and C' and C aren't the
same), and it will actually re-insert B - which was buggy - before it
finally gets to the commits _you_ actually did (a, b and c).
So no, you canno even sanely rebase on top of another persons rebased
tree, because the _other_ person threw away his history, and since you
remember their _old_ history, it's basically now you who are in charge of
it.
What you can do is to basically do
git fetch nasty-tree
git rebase C.. --onto nasty-tree
ie you can explicitly _tell_ rebase which commits you want to rebase.
Obviously, "git rebase --interactive" can help you do this (ie you can get
the whole list and edit out all the crud that you know isn't yours).
But this is why working on top of somebody elses tree that gets rebased is
so hard. You lose all the history, because the other person basically
threw it away and started over.
Don't get me wrong - it's _possible_ to do. See above about how you can
pick-and-choose the parts you decide you want to keep (your "own" stuff).
In fact, we could even do a form of "rebase" that only picks commits that
you committed yourself, and call it "git rebase --my-commits nasty-tree",
and that would often do the right thing (assuming the source tree only
ever rebases its own commits, of course! If it rebases other peoples
commits, it's so terminally broken that you should just refuse to work
with that tree, and shoot the maintainer)
So we could do more helper functions for this, but the fact is, it's a
really broken model. The real fix is to teach people not to rebase.
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
