On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:

quoted text
>

> you got nice and detailed answers,  for example you can track a

> rebased tree in your working directory using git pull --rebase.

> What's wrong with that?

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