Fixing rebase rather than avoiding it

[Óscar Fuentes]

"Matthew D. Fuller" <fullermd at over-yonder.net> writes:

>>  > > Revision 2 is identical to revision 1.1.1
>>  > 
>>  > Then why would you have to rebase it, instead of just sticking it
>>  > on the head of the branch as-is?
>> 
>> You don't *have* to rebase it.  In certain workflows, it is a
>> sensible choice.
>
> I don't see how.  It's barely even _meaningful_.  You're creating a
> new rev with the same contents, committer, timestamp, log, and parents
> as an existing rev.  It's nearly exactly the same; in bzr, I expect
> the revid to be the only difference.  If you did it in git, I'd think
> even the id would be the same, since all the info it's based on is the
> same.
>
> The only time you'd need to rebase to pop it on the end of the branch
> is when some part of that (at least the parent[s] list) has to change.
> But that's the separate situation wandering through the rest of the
> mail.

So okay, let's suppose that mainline diverged while you were working on
your local branch. Then you argue that rebasing would destroy the
information about the branch point where your work started. Well,
sometimes that information is valuable. Sometimes is not.

My point here is that there scenarios where rebase makes sense. I'm not
proposing to rebase when a merge is the right thing. The argument about
throwing out valuable information is silly. It is the user, not the bzr
designers, who decides what information is valuable and what's not.