lkml.org 
[lkml]   [2008]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Please pull ACPI updates


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


\
 
 \ /
  Last update: 2008-07-17 22:19    [W:0.088 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site