Re: Removing rollback from VC mode - request for comment

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > Rebase is a different operation. It's forward composition after
 > you've chopped off a last segnment.

And?  Certainly, there are several ways you could define "commit
deletion", but this is equally certainly one of the reasonable ones.

 > It's...quite different.  I had to wrestle with this when implementing
 > commit deletion in reposurgeon.

There are at least three concepts of commit deletion.  All are
implemented in git.

The first is removing the effects on content but not the history in
the DAG.  git implements the command "revert" for this purpose.[1]
The second removes both the effects and the history.  git implements
the command "rebase" for this purpose.  Finally, one may wish to
remove the history, but not the effects.  git (in its gittishly
inimitable way) provides several ways to accomplish this: the "squash"
operation of the "rebase --interactive" command, the "--squash" option
to the "merge" command, and the ultimate generalization of all of the
above, the "filter-branch" command.

In git-like DAG implementations, all history alterations require
recreation of "forward history" as well.  It's theoretically possible
to equivalence commits (eg, git provides grafts) but as far as I know
there are no VCSes that try to do this automatically and consistently
through all DAG operations.  That is indeed a hard problem.  Bottom
line, in existing DAG-based VCSes, there is either no way to actually
remove commits, or the human keeps track of the equivalencing of
descendant commits in lieu of a Sufficiently Smart VCS.

Footnotes: 
[1]  Introspection suggests that "commit deletion" is a bad way to
describe this.  I don't know for sure that others feel that way, and I
include it for symmetry/completeness.