[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: RCS, again: another removed functionality: undo last-checkin
Date: Wed, 23 Sep 2015 09:58:40 +0300

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Wed, 23 Sep 2015 08:54:18 +0300
> On 09/22/2015 10:05 PM, Eli Zaretskii wrote:
> >> And if we're going to warn about doing rollback either way, the second
> >> warning is more likely to fly under the user's radar ("why are you
> >> asking me this again? yes already!"), which is kinda bad.
> >
> > I meant a single warning, not 2 of them.
> That sounds non-trivial: how is generic code to know that the Git 
> backend intends to fall back to 'git revert'? Would warnings be 
> backend-specific?

With such a difference in back-end implementation of a rollback, it
would be appropriate to have a separate back-end method that produces
the warning language.

> And having just one warning means it has to convey both the sense of 
> danger *and* the choice of Git command to be used.

Probably a good idea, but having the back-end produce the warning, I
think it's solvable.

> So I think vc-rollback should error out (by default; that could be 
> customizable) when the user tries to back out of an already-published 
> commit (and the backend knows how to detect that), and suggest using 
> vc-revert. Which will be a separate command.

But then what will we do with back-ends where there's only one command
for a rollback, and it works regardless of whether the the commit was

reply via email to

[Prev in Thread] Current Thread [Next in Thread]