Workflows, rebase, patch theory (was: [Bug 227340] [NEW] Simple way to prepare patches for submission)

[Andrew Bennetts]

Ben Finney wrote:
> Andrew Bennetts <andrew at canonical.com> writes:
> 
> > So you want something that generates a series of patches, one per
> > commit? I'm a bit ambivalent about that, as that's the sort of
> > behaviour that encourages (and is encouraged by) rebasing, which has
> > significant drawbacks. I'd prefer to find a way to satisfy your need
> > that doesn't encourage rebasing if possible.
> 
> For someone who was introduced to DVCS via GNU Arch -> baz -> bzr, and
> who hasn't used git, all this talk of "rebase" is foreign. (It also
> doesn't help that the Debian package 'bzr-rebase' has a description
> that assumes the reader already knows what "rebase" means.)

Have you seen the description at <http://bazaar-vcs.org/Rebase>?  (Which is the
same text that "bzr help rebase" gives with the plugin installed, I believe.)

To my eyes it gives an ok description of rebasing, but then I know what it
means...

To "rebase" is to take a series of changesets (from an existing series of
revisions), and generate a new series of revisions against some designated base
revision, one new revision per original revision.  Commit messages are
preserved.

So say you have:

A -> B -> C -> D
 \
  -> E -> F -> G

You could use rebase to generate:

A -> B -> C -> D
                \
                 -> E' -> F' -> G'

(Heh, I just noticed this essentially the same example as used in
http://git.or.cz/gitwiki/GitFaq#head-1168c3027a2b7060df8c5cf141756c8e0e33139c)

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.

The big disadvantage is you're throwing away history — and if other 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/ 

AIUI git people mainly use rebase so they can treat branches (i.e. series of
revisions) like a stack of patches.  It's better than keeping patches by hand
because the vcs helps keep the patches up to date w.r.t. to the trunk.  I
suspect people like the direct relationship to patches because it makes sending
changes to an upstream that doesn't use the same VCS easier.

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

-Andrew.