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?
Are you saying that one user would use "newrebase" and some other would
use "merge" and that they'd get conflicts because the end result
is different?  Hmm... I can guess that can happen, but I'm not convinced
it would be a significant problem.
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.

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

> Note that this has the problem that branches sprouting from C1, C2, or
> C3 are still screwed,

In which sense?

> even though strict mirrors of B2..C3 will be handled correctly.

>> (where C1' and C2[ab] are cleaner/better/more palatable than C1 and C2).
>> Here you'll want to deprecate C1 and C2, but if your branch is
>> published, you need to keep info about them.  To avoid rewriting
>> history, you may prefer to use something like:
> Sure, but this is not a rebase in any sense.  I agree that I want to
> be able to substitute a new public history in this way sometimes, but
> I would not call it rebase.

Agreed, it's not a "rebase".

> Again, what about branches that sprout from C1 and C2?

Again, what about them?

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


        Stefan