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

[Dmitry Gutov]

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?

> 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.

> 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 think it does: if you commit a change in an outdated file, your
> commit will either be rejected or, worse, will wipe out later commits.

Maybe you have a point there. Keeping that piece of logic in vc-commit 
too doesn't sound too awful.

> A maintainer can "just do it", of course, but he/she cannot prevent
> others from reacting to a commit after the fact.  So I don't see any
> way of avoiding discussions in general.

I mean "just do XXX" as a response to that kind of discussion. Either we 
have a new workflow to do the same thing, or we say that, alas, the 
users need to use the console for that operation now. And life goes on.

> If my recollections are wrong, I apologize.  I did re-read them when
> Uwe complained about the change in vc-checkin's behavior.

Even if Eric had some emotional reasons for that change (I don't 
recall), we did bring up more practical benefits for it in Uwe's thread.

> 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.