Workflows, rebase, patch theory

[Daniel Pittman]

Ben Finney <bignose+hates-spam at benfinney.id.au> writes:

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

The operation is, essentially, to change the starting point of a graph
of changes from one point to another:

From:

  o--------o---------o
   \---o-----o----o-----o

To:
  o--------o---------o
                     \---o-----o----o-----o

The effect, once you do all your merging, is as if you started your
development against the newer base version in the main branch.

> Why is a "rebase" operation desirable or undesirable (pros and cons,
> advantages and drawbacks)?

The advantage is that you are presented with a very clean development
history: when you merge the rebased branch into the source branch you
don't see a lot of merge noise or whatever during the development cycle.

For a long-lived branch this can be a significant volume of noise
avoided, and can also ensure that your main branch *always* compiles,
because you never have a "broken merge + fixed" pair of changes, only a
"correct merge" single change.


The key drawback is that you discard facets of the information about the
branch: when it really started, how it developed and changed over time,
what the developer was thinking when they built it, and what mistakes
they made.

In my opinion, and this isn't uniformly shared, rebase is most useful in
two cases: ensuring 'bisect' always works, and pretending that your
developers never make any mistakes.

The first is reasonably valuable, but much less so if you can bisect
over branch merge points as a single item rather than as individual
changes.

The second is ... much less useful, in the long term, that being able to
find out why someone did what they did and all the associated mess that
surrounded the real development effort.


On a trivial basis the same developers often prefer an "amend" type
operation where they can go back and edit changes that have already been
committed to history through any distance -- it provides the same sort
of "clean history with mistakes elided" output.


In both cases -- rebase and amend -- this can cause significant grief if
they rewrite history after it has been shared with another repository.

Regards,
        Daniel