Fixing rebase rather than avoiding it

[Óscar Fuentes]

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.

[snip]

>> 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. I'm not use how well `bzr ci --local'
when upstream diverged. `bzr switch' forces you to create branches and
then send them upstream one at a time. In practice, this creates a fair
amount of administrative work.

[snip]

>> Another good use of rebase is for those who do quickfixes the
>> "distributed way". They are contributing histories like this:
>> 
>> 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.