Fixing rebase rather than avoiding it

[Óscar Fuentes]

Eli Zaretskii <eliz at gnu.org> writes:

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

The others create more extra work than rebase or, in the case of commit
--local, the same amount of work, supposing that it does the right thing
when it sends the changes upstream. 

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

qlog is just an example. Everything in bzr is slowed down a bit
everytime a revision is added to the history. AFAIK, if the revision
does not belong to the left hand of the branch, it adds an extra
overhead.

> And don't use -n0 if you are bothered by the extra commit messages.

If -n0 is not to be used, don't merge. If it is useful, merge something
meaningful so others don't waste their time skipping over useless junk.

[snip]