On Thu, 17 Jul 2008, Linus Torvalds wrote: > > In particular, if something worked for somebody before, it also removes > the "known good state" from a bisection standpoint, so rebasing actually > makes things _harder_ to bisect - because now you cannot sanely bisect > between two versions of the tree (when you mark the old tree "good", it > has no relevance to the new tree that had all the old history rewritten). Let me do a made-up example of this just to kind of illustrate the point. Let's say that _I_ rebased history to always make it linear. That would obviously make things much "easier" to bisect, since now it's just a linear list of commits, and bisection is just taking the midpoint of that list and trying it. Right? Also, I'd fix up the linear list so that any found bugs are squashed into th code that caused them, so all _known_ bugs are non-issues from the standpoint of bisection: because the code you are bisecting already has those removed entirely. That's a clean nice linear history with no unnecessary breakages (no compile failures, no other unrelated and solved bugs) for bisection, so bisecting new bugs must be much simpler, right? WRONG. It means that a person who ran my tree as of yesterday, and had a working setup, but then updated to my tree as of today, and things break, can no longer bisect sanely AT ALL - because the state that he was at yesterday is basically completely *gone*, because it has been cleaned-up and sanitized, since I happened to rewrite history from a week ago due to finding a bug. Also, related to the same thing, if that person had some patches of his own that he was working on on top of the state I had yesterday, since I rebased, it's now almost impossible for him to be able to judge what is really _new_ stuff, and what is just the old stuff he was working on, except it's been cleaned up and sanitized. But at the same time, the new history is clearly _simpler_, isn't it? Yes, it is simpler, BUT ONLY IF YOU DON'T TAKE INTO ACCOUNT THAT SOMEBODY ALREADY SAW AND USED THE _OTHER_ HISTORY YESTERDAY! I'm shouting, because this is really really important from a very fundamental standpoint. It's not just important from a git standpoint: this really is _not_ some odd git-specific implementation issue. No, it's much much more fundamental than git. It's a very basic fact that woudl be true with _any_ SCM. So git just happens to encode that fundamental truth a bit more explicitly and make it very obvious. Git is very careful at _not_ losing that state as it existed somewhere yesterday. So rebasing and cleanups may indeed result in a "simpler" history, but it only look that way if you then ignore all the _other_ "simpler" histories. So anybody who rebases basically creates not just one simple history, but a _many_ "simple" histories, and in doing so actually creates a potentially much bigger mess than he started out with! As long as you never _ever_ expose your rewriting of history to anybody else, people won't notice or care, because you basically guarantee that nobody can ever see all those _other_ "simpler" histories, and they only see the one final result. That's why 'rebase' is useful for private histories. But even then, any testing you did in your private tree is now suspect, because that testing was done with the old history that you threw away. So even if you delete all the old histories and never show them, they kind of do exist conceptually - they existed in the sense that you tested them, and you've just hidden the fact that what you release is different from what you tested. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
