Workflows, rebase, patch theory

[Ben Finney]

Andrew Bennetts <andrew at canonical.com> writes:

> AIUI, git users tend to use this to keep their changes up to date
> and "ready for submission" with respect to a trunk. The advantage is
> you don't have commits like "Merge bzr.dev" interspersed with your
> own changes.

Okay. This does seem to be a main complaint against Bazaar and
Mercurial by Git or Darcs users. I don't understand why it's desirable
to hide merges in the history, especially against...

> The big disadvantage is you're throwing away history

Yes.

> — and if othe people have branched off you, you are headed for
> massive merge conflicts: there are two branches with very similar
> changes but no common revisions for those changes. Even Linus has
> said he doesn't like rebasing: http://lwn.net/Articles/269120/

Thanks. (The article discusses the topic well; Linus's specific
message decrying "rebase" is at <URL:http://lwn.net/Articles/269210/>.)

One thing I don't understand in Linus's complaint is:

    "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? 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?

> But we have a more powerful, history-preserving tool in development
> that should cover the same use-cases: looms.

I find no <URL:http://bazaar-vcs.org/Loom> or
<URL:http://bazaar-vcs.org/Looms> page. Where can I read about this?

-- 
 \            "Beware of bugs in the above code; I have only proved it |
  `\               correct, not tried it." -- Donald Knuth, 1977-03-29 |
_o__)                                                                  |
Ben Finney