Fixing rebase rather than avoiding it

[Stefan Monnier]

>> >> Doesn't matter.  Even if I do "bzr merge" twice in the same day, I may
>> >> not resolve the conflicts in the same way, and even less so if I pass
>> >> different --merge-type arguments.  So this "discrepancy" would not be
>> >> anything new.
>> > The point is that it would become more frequent.
>> What is "it"?  What would become more frequent?
> It == such discrepancies.

Then I don't understand why that would be a problem.

>> > An extreme example of proper use of a rebase is a typo fix 'hte' -> 'the'
>> > in a comment or string.
>> The kind of "proper use of rebase" I'm thinking of, is a feature-branch
>> that tracks the upstream branch and wants to present a "clean set of
>> patches" no matter how many years it has to keep merging from the
>> upstream branch until it is finally merged upstream.
> And you want to preserve history.  OK, so this means that commit
> storage and tree storage will grow at least as O(N^2) where N = # of
> rebases, IIUC, unless you do something tricky.

Why?  Compared to a "merge", the only difference is that each
"newrebase" will create M commits rather than just 1, where M is the
number of local patches.  I don't see where you get your square factor.

> The DAG is also going to be pretty hard for humans to read, you know,
> because you're maintaining a set of N branches of lengths proportional
> to M/N, 2*M/N, ..., (N-1)*M/N, where the proportionality factor is
> 1 + M(trunk)/M(feature branch).

The shape of the DAG will be identical to the one you'd get with
"merge"s, except that the arcs from the upstream to the local branch
corresponding to merges get split into a path of M+1 arcs through
M intermediate commits.

As agreed earlier, the added arcs (compared to a plain rebase) would be
considered as "obsolete" and so we wouldn't have to show them (we could
even give them a limited lifetime).

>> > Note that this has the problem that branches sprouting from C1, C2, or
>> > C3 are still screwed,
>> In which sense?
> Those branches will not "know about" the rebase, and attempts to merge
> them into the mainline will generate spurious conflicts.

Not more than if a "merge" had been used instead of a "newrebase".
And much less than if a "rebase" had been used.

>> > If I used the word "pull", I'm sorry.  "bzr pull" never applies any
>> > patches, it just downloads revision data.  What I meant was what
>> > everybody else calls "pull" and bzr calls "merge --pull".  In that
>> > case you can indeed get conflicts that would not have happened without
>> > the rebase.
>> Could you give me a scenario where you'd get additional conflicts?
> Any time the post-rebase code reverts rebase code, for example.

You're going to have to be more concrete and specific if you want me to
understand what you're alluding to.


        Stefan