Fixing rebase rather than avoiding it

[Ben Finney]

Talden <talden at gmail.com> writes:

> > * “I don't like to see existing history in that manner” (in which case,
> >  the problem is to allow *that user* to see it a different way), or
> >
> > * “I don't want anyone to see existing history in that manner” (that's
> >  not for you to decide on behalf of everyone else).

[…]

> It's my branch and I can do what I like. Heck I can even write some
> python against the bazaar API and redo those commits myself. The
> moment I publish my branch or send a merge-directive they're public
> and it's irresponsible to fiddle with that history.
>
> That you say someone else holds rights to view history I've not chosen
> to release is exactly the opposite extreme.

You appear to have parsed my words differently from how I intended.

The referent of “that” in the above second point is specifically
referring to viewing the published history data in a particular manner.

Yes, it's for the branch owner to decide whether and when to publish
revision data. What's not for the branch owner to decide is *how* others
will find it useful to view that published revision data.

The history needs to be preserved so that the commit operations that
resulted in that published data can be reconstructed if needed at some
future point by some interested party. The use case I usually have in
mind is forensics (“how did this big change actually get assembled, and
what went wrong?”), but I recall other plausible cases being presented.

-- 
 \     “I got some new underwear the other day. Well, new to me.” —Emo |
  `\                                                           Philips |
_o__)                                                                  |
Ben Finney