Re: RCS, again: another removed functionality: undo last-checkin

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 23 Sep 2015 00:49:59 +0200
>> 
>> IMHO it would be wrong to implement a command that does one thing or
>> another depending on the backend.
>
> With such different philosophies between different back-ends, we
> really have no choice.  Keep in mind that this command is supposed to
> be used very rarely, if at all, by users who know what they are doing,
> including what it does with the current back-end.

A command that is supposed to be used very rarely, if at all, by users
who know what they are doing is a command that does not deserve a
keybinding, and arguably no VC command at all since the whole point of
VC is to save the user from knowing what they are doing with a
particular backend.

That being said, I am _constantly_ using "git rebase -i" in order to
rewrite the history of a patch series I am preparing for submission or
fixing.  It turns out that this is a much more frequent command in my
workflow than explicitly undoing the last commit ("git rebase -i" can be
used to undo the last commit, but it also can be used for undoing or
modifying any particular commit since the branch-off point).  So for me,
a keybinding for "git rebase -i" would be warranted.  While one can
naturally also do a lot of damage with "git rebase -i", every piece of
damage one does with it relies on additional explicit actions, namely in
edits to the task description (which defaults to "no change", either
when you delete the whole task description or leave it completely
unchanged) before it gets submitted.

Mapping some generic "change history" command to "git rebase -i" when
there is a "merge base" would include the ability to drop the last
commit (just kill the last line in the task description).

-- 
David Kastrup