Fixing rebase rather than avoiding it

[Eli Zaretskii]

> From: Óscar Fuentes <ofv at wanadoo.es>
> Date: Thu, 04 Mar 2010 15:40:57 +0100
> 
> Eli Zaretskii <eliz at gnu.org> writes:
> 
> >> rebase is safer than working on a bound branch
> >
> > ``Safer'' in what way?
> 
> You can hold your commits locally until you feel it is time to send them
> upstream.

That's possible in any number of ways that don't involve rebase.

> >> If I were off-line and in the mood of doing a few quick fixes I'll pile
> >> them on a single branch and later send them upstream with rebase &&
> >> push. This would save lots of time.
> >
> > There are alternatives to this workflow that don't involve rebase, of
> > course.  E.g., "bzr ci --local", or "bzr switch", or ...
> 
> Both of those create extra work.

So does rebase.  Delaying commits always creates extra work.

> >> 5 Fixed bug #432
> >>   2.1.4 Merge from trunk
> >>   2.1.3 Fixed bug #432
> >>   2.1.2 Merge from trunk
> >>   2.1.1 Merge from trunk
> >> 4 ...
> >
> > Right.  And FWIW, I never understood why this bothers people so much
> > to warrant long repeated discussions such as this one.
> 
> You don't see a problem with that? Well, apart from the obvious (it is
> just junk that wastes your time when reading the history) it slows down
> bzr even more: for one change, 5 commits, one of them a merge. Do `bzr
> qlog' and you will see what I'm talking about.

If "bzr qlog" hurts, don't use it.  And don't use -n0 if you are
bothered by the extra commit messages.  (But others already said that
before me.)  I'm not bothered by these messages; it's easy to skip
them.  Also, "bzr log" is not supposed to be such a popular command in
the current Emacs development model, so a bit of performance hit
shouldn't matter.