Fixing rebase rather than avoiding it

[Stefan Monnier]

> rebase operation.  Does it help if I mention that this common case is
> what GNU Arch calls a "tla update"?
> OTOH, rebase itself is implemented in the same way as "tla replay",
> but the semantic contexts are different.  "tla replay" is intended to

That's also the way I think about it ;-)

> That's not what I meant by "day-to-day operation".  I'm talking about
> "when would you care to know that the branch was rebased?"  IMO, in
> day-to-day operations, the answer is mostly "don't bother me with such
> trivia, just DTRT."  IMO most users would want to be notified of the
> rebase at pull time, would then go look at the new log of the rebased
> branch a little more carefully than usual ... and very likely never
> again refer to the obsolete history's log.  The only time I can
> imagine is when doing forensic analysis on really mysterious breakage.

Just as in tla, since my rebase could be used in place of merge, and so
I'd expect it to become a very common operation (it's basically a merge
which adds N commits on top of the destination's head rather than just
one).

> When would you refer to the obsolete history?

Any time you need to merge/update/pull a branch that referred to
that history.  Or for forensic analysis of course, since that "obsolete"
branch would hold the "true real history" ;-)


        Stefan