Workflows, rebase, patch theory (was: [Bug 227340] [NEW] Simple way to prepare patches for submission)
bignose+hates-spam at benfinney.id.au
Wed May 7 03:19:18 BST 2008
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.)
I've heard a lot of talk about "rebase" from git and darcs users
(though the darcs users don't use that term, they do seem familiar
with the concept in discussion).
What is "rebase", and what does it mean for a Bazaar branch?
Why is a "rebase" operation desirable or undesirable (pros and cons,
advantages and drawbacks)?
\ "I used to be an airline pilot. I got fired because I kept |
`\ locking the keys in the plane. They caught me on an 80 foot |
_o__) stepladder with a coathanger." -- Steven Wright |
More information about the bazaar