Workflows, rebase, patch theory

[Stephen J. Turnbull]

Ben Finney writes:

 > > The big disadvantage is you're throwing away history
 > 
 > Yes.

I don't understand why people keep saying this when it quite obviously
isn't true.  The only time git ever throws away history is when you
run "git-gc --prune".  What happens in git-rebase is like ripping a
page from the index of a history book while leaving the descriptive
text intact, not like ripping out a chapter.  Oh, and I guess you
then scribble a new summary of the chapter on the flyleaf so you can
find it easily.

So what *is* true is that the link between a branch name and a certain
history is broken by rebasing.  This is a genuine, important problem,
but if you identify it as "throwing away history" then you probably
are eliminating a large fraction of the possible ways to solve it.

 >     "Now [in a hypothetical scenario] I've merged (say) 1500
 >     networking-related commits by rebasing, but because I rebased on
 >     top of Greg's tree that I had also rebased, absolutely *none* of
 >     that has been tested in any shape of form."
 > 
 > Isn't part of the point of "rebase" that the working tree ends up
 > exactly the same as if a "merge" was done?

No; you can't guarantee that will happen, because in both cases
conflicts may occur that must be resolved.  However, they will be
resolved in different contexts and therefore are at least somewhat
likely to be resolved differently (presumably by mistake...).

It is pretty likely that you'll end up with the same tree, though.

 > Why, then, does Linus claim "none of [the changed code] has been
 > tested"? Don't all existing tests continue to apply, if the working
 > tree is the same?

No, because in Linus's scenario the working tree is the same as the
merged tree, but it is *not the same as any tree on which the tests
were run*.  And in fact *no revision in the rebased history* is the
same as any tree on which the tests were run.

AFAICS, nobody claims that merging leads to a situation where the
tests have been passed by the working tree after merging ... unless
they've been run again.  Which is pretty clearly what several posters
were assuming (eg, Ian saying that you can avoid merge turds by doing
the merge without committing, run the tests, do the fixes -- and run
the tests again, I am sure -- and then commit).

Andrew's point about bisection is that if there is a problem with the
merge, the most recent revision that did pass the tests is in the
history up to the merger, so you can start bisecting there instead of
with the empty tree. :-)