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