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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 1 Oct 2015 05:47:54 +0300
> 
> On 09/30/2015 05:13 PM, Eli Zaretskii wrote:
> 
> > Well, with RCS as the back-end, "register" actually commits.
> 
> That's... odd. How does it do that before the user entered the commit 
> message?

RCS has its default for the initial commit's log message.  I think you
can override that with a prefix argument, but few people do.  You will
see that default in many of the first commits in the Emacs
repository.  A short excerpt:

  a0cf9a6 1987-03-03 Noah Friedman     Initial revision
  248b25a 1987-01-22 Richard Stallman  Initial revision
  b20cd8d 1987-01-07 Richard Stallman  Initial revision
  62983f7 1986-09-29 Joseph  Arceneaux Initial revision
  bd1411a 1986-09-18 Richard Stallman  Initial revision
  2c4b8b1 1986-09-14 Jim Blandy        Initial revision
  47bdd84 1986-09-12 Jim Blandy        Initial revision
  ff9c6df 1985-12-14 Jim Blandy        Initial revision

> > I see
> > that the other back-ends only use the "add" sub-command, but maybe we
> > should change that, so registering ends up with the files committed.
> 
> Maybe we should just call that action "committing", and assume that 
> registering, if needed, is a part of it. Doing it another way would 
> sound pretty weird to me.

Sounds good to me, modulo existing habits.

> > I don't think there are such back-ends.  The only issue with such a
> > change that I see is that people might want adding files
> > incrementally, then committing them all at once.  If this is something
> > users might do a lot, perhaps we should have a defcustom for such
> > behavior.
> 
> Git users are accustomed to 'git add' moving changes to the staging 
> area, which is pretty neat, but one needs to 'git add' both unregistered 
> files *and* files that simply have new changes. That's mismatch #1.
> 
> Mismatch #2 is that no other VCS (AFAIK) has a staging area. So it's 
> much simpler to avoid that intermediate step, since it can't be 
> implemented in a generic fashion.

I agree.

> > I agree, but the features in question do make sense, I think, because
> > the back-ends they were written for still exist and are supported and
> > used.
> 
> That would imply that e.g. every Git or Hg feature makes sense in VC. 
> But we only support those we can abstract over in a reasonable fashion.

I was talking specifically about features that existed for a long
time.  Introduction of new features is, of course, another matter, and
I agree with you that not every feature of every VCS should be in VC.