Workflows, rebase, patch theory

[Ian Clatworthy]

Matthieu Moy wrote:
> Ben Finney <bignose+hates-spam at benfinney.id.au> writes:
> 
>> I don't see how "information about what happened when" is "noise",
>> especially in a system that's designed to preserve exactly that
>> information — which is what a VCS is designed to do.
> 
> If you have to review a patch serie, you don't care about the mistakes
> fixed later in the serie, you don't care about when the author of the
> patch merged from upstream, ...

I'd like to hear more about why you think reviewing the patch *series*
is even useful/necessary. I review dozens of patches each month and I
never feel the need to do that: I review the *overall* change, not the
steps the developers took to get there. Also, the whole change gets
accepted or rejected - I never want to say "I'm accepting steps 1-4 and
6-7 but 5 can't land."

> There is a _huge_ difference between the published history, shared by
> everybody, and your own private space. The history you publish is a
> description of the logic between the starting point, and the end
> point. Your private history can contain your mistakes and mess, but
> you're the only one who may need it.

If you have a private branch and you don't want to keep its history, you
can easily throw it away by generating an overall diff and applying that
to the latest trunk:

  (in private branch)
  bzr diff -rsubmit: > ../my.patch
  (in public branch)
  bzr update
  patch -p0 < ../my.patch
  # resolve conflicts and run tests
  bzr commit -m "blah blah blah"

There are times when I use that process pattern but it's a rare thing.
Quite honestly, there's deep value for the overall team in me including
whatever mistakes I may have made in public history. Perhaps they
indicate that we need more doc in any area or a better API? I'd rather
have history telling me stuff like that than have developers pretending
everything went swimmingly well. Software nearly always takes longer
than we expect. Let's stop throwing away useful data that helps us
understand why!

To put it another way, I don't feel developers ought to be rebasing to
make themselves look good. If your processes are focussed on reviewing
an overall change (not a patch series) and that overall change is merged
(not pushed) to a mainline, rebasing for the sake of cleaning up interim
history is arguably helping my ego more than it is helping the team.

To be clear, I'm not against rebasing - it's a useful tool at selected
times, but I do think it's a mistake to be making it a standard part of
one's modus operandi. If anyone is telling you that rebasing is a best
practice, I'd provocatively suggest they are more interested in looking
good to their peers than collaborating with their peers. Time for me to
duck for cover about now ... :-)

Ian C.