Fixing rebase rather than avoiding it

[Talden]

> I would think the correct middle ground is:

> * Always record all changes (don't rewrite history), and

Denying any history editing isn't middle-ground (I don't think there
is a middle-ground FWIW)

> * “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).

Yes it is, just as it's my choice what to commit.  Note that I've
referred specifically to revisions not in a public context but in a
private one.

I can choose to:

* commit often...
* commit once leave committing until 2 months later...
* commit just before that flight where my laptop might get damaged and
I wouldn't want to lose work (but haven't run tests or even reached a
compilable point)...
* commit, uncommit, commit, uncommit...

Being the author I'm certainly the most qualified to decide which were
meaningful to anyone receiving these commits from _my_ branch.

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.

> The problem always comes down to “whoops I crossed the line between
> rebase-safe and not-rebase-safe”, and it's always *someone else* paying
> that price, some indeterminate number of times and some indeterminate
> point in the future.

That's more about access control than feature-set - after all, with
unrestricted access anyone could do that now to the bazaar code-base -
of course no-one of an irresponsible nature has commit/write access
(fingers crossed, after all you don't need the UI, you already have
everything you need in the bazaar API)

> The problem needs to be avoided at the source, by not having *any*
> operation make *any* revision incompatible with other branches that
> share ancestry.

Better remove uncommit and forget-merges and all of those kinds of
operations then (and an APIs that might facilitate writing them)... Of
course that's absurd, instead you have networks of trust and
appropriate access control.

>> In every other way it makes Bazaar more inclusive. Bazaar supports
>> many workflows now and more are supported with this functionality -
>> with it Bazaar will be useable/acceptable in more projects.
>
> I think history-viewing flexibility is the answer: always keep all
> revisions, and allow each user to filter their view of history or drill
> down to see it all if they choose.

I think we absolutely want both (along with rich searching facilities
and any number of other features).

In work I do I would expect to only rarely use history re-writing and,
barring only a handful of instances, never on published commits.
There are occasions though and some have been significantly
non-trivial (meaning the silly uncommit, merge, forget-merge, commit,
dance is completely impractical).

--
Talden