Fixing rebase rather than avoiding it

[Talden]

On Thu, Mar 4, 2010 at 11:13 PM, Matthew D. Fuller
<fullermd at over-yonder.net> wrote:
> On Thu, Mar 04, 2010 at 04:22:52PM +0900 I heard the voice of
> Stephen J. Turnbull, and lo! it spake thus:
>> Matthew D. Fuller 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.

Yes I don't see that as such a meaningful use of rebasing. In fact
you're potentially throwing away something useful, that the delivery
into a published branch wasn't originally developed there (branch
nick), was possibly written by a different person and the content of
that merge revision may not actually be textually identical (conflict
resolution) to the merged revision (and so any statements of
performance, stability, etc may actually be false).

If I submit a branch X with one revision x to be merged into branch Y.
 I wouldn't want the branch Y person throwing away that identity
information.  After all, my branch history is important too and once
any two people have a revision it's 'public' and shouldn't be thrown
away - what if I'm still using branch X and want to pull back from Y
later.

A good UI can and should provide protection via some definitions of
strictness (albeit overrideable).

--
Talden