[lkml]   [2008]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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?


    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,

    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

    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.


     \ /
      Last update: 2008-07-17 22:19    [W:0.024 / U:10.688 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site