Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Stefan Monnier writes:

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

 > E.g. I haven't ever seen any complaint about such problems due to
 > one guy using one particular merge-algo and someone else using
 > another.

That's because it's very rare that they do such a thing with the same
parents, and because most of the time different algorithms give
basically the same results because the "changesets that don't change
the same file can't conflict" heuristic is so frequently applicable.

With your rebase stategy, though, it would be happening automatically.

 > > 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.  (File storage still
grows as O(M) where M = # of commits, I think.)  I think the
annotation strategy can be more easily optimized for space, here,
although I don't know how much commits and trees cost in bzr.

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).  (I'm doing the computations in my
head so I could easily be wrong, but these are not happy numbers if
I'm right.)

Is this really going to be useful?

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

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