Workflows, rebase, patch theory

[Andrew Bennetts]

Ben Finney wrote:
> 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.

Right :)

> > — 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/>.)

Yep, as usual LWN is excellent.  It's about time I renewed my subscription...

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

I suspect he's referring to the newly-generated intermediate revisions.  If the
intermediate revisions have never been tested, then the usefulness of bisect is
greatly reduced.  More subtly, the history is "fake"; it's not how the code
really evolved, so the decisions made in any particular revision might not
actually make as much sense as they did in the real history.  So you have a
superficially neat history (no merges), but a less trustworthy one if someone
ever needs to examine that history.

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

<https://launchpad.net/bzr-loom>, which also links to
<http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/annotate/head:/HOWTO>.

It's still fairly new.  If you have any feedback or questions about it, please
post to this list about it, we'd love to hear it.

-Andrew.