Re: nicer frontend to get rebased tree?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:
>
> 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