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

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

[Uwe Brauer]

Hello

I did not want to bring up this subject yesterday when the discussion
about vc-checkin/vc-rcs-checkin allowing an additional optional
argument, was still going on.


But as I learned from David and Eli that ESR, removed another feature, namely
undo-last-checkin AKA rollback.

I confess I have no idea how this concept makes sense in git and
friends but I know that it makes a lot of sense in RCS.

Here is a scenario:

I collaborate with somebody, by email,  about say an
article. The collaborator does not use any VC at al.

It happened more than once that I obtained some version from him, checked
it in and then heard «sorry this was the wrong version here comes the
right one».

Now if I have undo-last-checkin function no problem, but if I don't
have, then the situation is a bit uncomfortable: I can checkin the new
one, but if I want to use vc-annotate, which I do often, then there is
one version which disturbs the workflow and I don't know how to get rid
of it.

So if it is not too much work could this functionally, for RCS, please
be restored?

Thank you

Uwe Brauer 

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

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sun, 20 Sep 2015 16:33:04 +0200
> 
> So if it is not too much work could this functionally, for RCS, please
> be restored?

Unlikely.  At least not unless we can come up with a suitable
interpretation of a "rollback" for other VCSes, in particular the
modern ones.  You may wish to read the discussion whose URL I posted
yesterday.

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

[Eli Zaretskii]

> Date: Sun, 20 Sep 2015 17:51:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Uwe Brauer <oub@mat.ucm.es>
> > Date: Sun, 20 Sep 2015 16:33:04 +0200
> > 
> > So if it is not too much work could this functionally, for RCS, please
> > be restored?
> 
> Unlikely.  At least not unless we can come up with a suitable
> interpretation of a "rollback" for other VCSes, in particular the
> modern ones.  You may wish to read the discussion whose URL I posted
> yesterday.

Of course, you can always do this with "rcs -oREV" from the shell, I'm
sure you know that.

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

[Uwe Brauer]

   > Of course, you can always do this with "rcs -oREV" from the shell, I'm
   > sure you know that.


Yes I do and I came up with a lisp wrapper for that:

(defvar vc-remove-command 		  "/usr/bin/rcs -o%s %s "
"*Command for removing rcs version from branch.")

(defun vc-rcs-remove-version ()	
  "Remove interactively versions from the tree."
  (interactive)
  (let* ((currentname 
		  (buffer-file-name (current-buffer))))
    (save-buffer)
	  (shell-command
	   (format vc-remove-command
			   (read-string "version to be removed: ")
			   currentname)
	   "*VC-RCS-LOG*")))

But I am not sure that anybody finds this useful.

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

[Stephen J. Turnbull]

Uwe Brauer writes:

 > But I am not sure that anybody finds this useful.

It is very useful, for people who treat VCS history as a script that
may be revised to improve presentation.  But for those who treat VCS
history as an audit trail (in some cases legally required or at least
extremely useful) rollback is a very dangerous feature.

I don't see any reason in a DWIMish front-end like vc.el to have the
rollback feature -- let those with the skills or the specialized use
cases use the command line or (for vc.el) write commands.

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

[Uwe Brauer]

>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

   > Uwe Brauer writes:
   >> But I am not sure that anybody finds this useful.

   > It is very useful, for people who treat VCS history as a script that
   > may be revised to improve presentation.  But for those who treat VCS
   > history as an audit trail (in some cases legally required or at least
   > extremely useful) rollback is a very dangerous feature.

   > I don't see any reason in a DWIMish front-end like vc.el to have the
   > rollback feature -- let those with the skills or the specialized use
   > cases use the command line or (for vc.el) write commands.

Just for the protocol: the vc pkg xemacs ships, still contains that
command!
,----
| 
| C-x v c runs `vc-cancel-version'
| 
| `vc-cancel-version' is an interactive compiled Lisp function
|   -- loaded from "vc"
| (vc-cancel-version NOREVERT)
| 
| Documentation:
| Get rid of most recently checked in version of this file.
| A prefix argument NOREVERT means do not revert the buffer afterwards.
| 
| Invoked with:
| 
| C-x v c
`----

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

[Uwe Brauer]

   > Unlikely.  At least not unless we can come up with a suitable
   > interpretation of a "rollback" for other VCSes, in particular the
   > modern ones.  You may wish to read the discussion whose URL I posted
   > yesterday.

Ok (sigh), I came up with a kludge, which serves my purposes, it seems.

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

[Stefan Monnier]

> But as I learned from David and Eli that ESR, removed another feature, namely
> undo-last-checkin AKA rollback.

The most natural way to re-add tihs feature is to make vc-rcs.el
understand the "Amend:" header that's also used by Git.

In Git, this lets you mark the current commit as replacing the last one,
instead of being a completely new one.  So it seems to be exactly your
use case.


        Stefan

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

[Uwe Brauer]

>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But as I learned from David and Eli that ESR, removed another
>> feature, namely undo-last-checkin AKA rollback.

> The most natural way to re-add tihs feature is to make vc-rcs.el
> understand the "Amend:" header that's also used by Git.

> In Git, this lets you mark the current commit as replacing the last
> one, instead of being a completely new one. So it seems to be exactly
> your use case.

Ok I have to dig into this in order to understand that feature.
thanks

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

[Uwe Brauer]

>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

   >> But as I learned from David and Eli that ESR, removed another feature, namely
   >> undo-last-checkin AKA rollback.

   > The most natural way to re-add tihs feature is to make vc-rcs.el
   > understand the "Amend:" header that's also used by Git.

   > In Git, this lets you mark the current commit as replacing the last
   > one, instead of being a completely new one. So it seems to be
   > exactly your use case.


But now I am confused, so  Git and I presume  hg provides for all
practical purpose a similar functionality. Why was it then removed. Ok I
confess I better read the links, which were provided by David and Eli
yesterday. 

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

[Dmitry Gutov]

On 09/20/2015 07:30 PM, Stefan Monnier wrote:

> The most natural way to re-add tihs feature is to make vc-rcs.el
> understand the "Amend:" header that's also used by Git.

The use case may be similar, but the name "rollback" sounds much closer 
to what happen when you call 'git reset [--hard]'. Which is a useful 
operation as well, one currently not supported by VC.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 02:24:22 +0300
> 
> On 09/20/2015 07:30 PM, Stefan Monnier wrote:
> 
> > The most natural way to re-add tihs feature is to make vc-rcs.el
> > understand the "Amend:" header that's also used by Git.
> 
> The use case may be similar, but the name "rollback" sounds much closer 
> to what happen when you call 'git reset [--hard]'. Which is a useful 
> operation as well, one currently not supported by VC.

If the commit was already pushed, you will need "git revert" instead,
I think.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Mon, 21 Sep 2015 02:24:22 +0300
>> 
>> On 09/20/2015 07:30 PM, Stefan Monnier wrote:
>> 
>> > The most natural way to re-add tihs feature is to make vc-rcs.el
>> > understand the "Amend:" header that's also used by Git.
>> 
>> The use case may be similar, but the name "rollback" sounds much closer 
>> to what happen when you call 'git reset [--hard]'. Which is a useful 
>> operation as well, one currently not supported by VC.
>
> If the commit was already pushed, you will need "git revert" instead,
> I think.

That depends on whether you are working on a branch considered to have
dependable commits or a preparatory/review branch.  People are expected
to deal with warped histories on preparatory branches.  As an example,
LilyPond works with a "staging" branch and a "master" branch.  "master"
only moves forward: once a commit is in there, it stays.  If its effects
are to be annulled, it is reverted.  Nobody pushes to master though.
Any changes are instead pushed to staging.  An automated task picks up
staging every few hours and if it has progressed ahead of master, it
makes a complete build of the state of staging, a documentation build, a
run of all regtests, and when all of that succeeds, it pushes the tested
state on top of master (only as a fast-forward, otherwise it fails.  And
it also tests that the current state of staging is the same or strictly
ahead of the tested state, so you can "stop the clock" any time before
the automated tests finish).  Every few months, someone will push
something to staging that does not pass the whole tests and builds.  In
that case the machinery stops before pushing anything to master, and
staging needs to be cleaned up.  This is not done with reverts but by
resetting the branch appropriately in spite of it being a public branch.

That's because people are expected not to maintain their personal
versions of the "staging" branch from which dropped changes could be
reintroduced.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 21 Sep 2015 09:25:33 +0200
> 
> > If the commit was already pushed, you will need "git revert" instead,
> > I think.
> 
> That depends on whether you are working on a branch considered to have
> dependable commits or a preparatory/review branch.  People are expected
> to deal with warped histories on preparatory branches.  As an example,
> LilyPond works with a "staging" branch and a "master" branch.  "master"
> only moves forward: once a commit is in there, it stays.  If its effects
> are to be annulled, it is reverted.  Nobody pushes to master though.
> Any changes are instead pushed to staging.  An automated task picks up
> staging every few hours and if it has progressed ahead of master, it
> makes a complete build of the state of staging, a documentation build, a
> run of all regtests, and when all of that succeeds, it pushes the tested
> state on top of master (only as a fast-forward, otherwise it fails.  And
> it also tests that the current state of staging is the same or strictly
> ahead of the tested state, so you can "stop the clock" any time before
> the automated tests finish).  Every few months, someone will push
> something to staging that does not pass the whole tests and builds.  In
> that case the machinery stops before pushing anything to master, and
> staging needs to be cleaned up.  This is not done with reverts but by
> resetting the branch appropriately in spite of it being a public branch.
> 
> That's because people are expected not to maintain their personal
> versions of the "staging" branch from which dropped changes could be
> reintroduced.

Thanks, but would this mean that "git revert" for a commit pushed to
the "staging" branch would be wrong?  If so, can you explain why?

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Dmitry Gutov <dgutov@yandex.ru>, monnier@iro.umontreal.ca,
>> emacs-devel@gnu.org
>> Date: Mon, 21 Sep 2015 09:25:33 +0200
>> 
>> > If the commit was already pushed, you will need "git revert" instead,
>> > I think.
>> 
>> That depends on whether you are working on a branch considered to have
>> dependable commits or a preparatory/review branch.  People are expected
>> to deal with warped histories on preparatory branches.  As an example,
>> LilyPond works with a "staging" branch and a "master" branch.  "master"
>> only moves forward: once a commit is in there, it stays.  If its effects
>> are to be annulled, it is reverted.  Nobody pushes to master though.
>> Any changes are instead pushed to staging.  An automated task picks up
>> staging every few hours and if it has progressed ahead of master, it
>> makes a complete build of the state of staging, a documentation build, a
>> run of all regtests, and when all of that succeeds, it pushes the tested
>> state on top of master (only as a fast-forward, otherwise it fails.  And
>> it also tests that the current state of staging is the same or strictly
>> ahead of the tested state, so you can "stop the clock" any time before
>> the automated tests finish).  Every few months, someone will push
>> something to staging that does not pass the whole tests and builds.  In
>> that case the machinery stops before pushing anything to master, and
>> staging needs to be cleaned up.  This is not done with reverts but by
>> resetting the branch appropriately in spite of it being a public branch.
>> 
>> That's because people are expected not to maintain their personal
>> versions of the "staging" branch from which dropped changes could be
>> reintroduced.
>
> Thanks, but would this mean that "git revert" for a commit pushed to
> the "staging" branch would be wrong?  If so, can you explain why?

It depends on whether the commit has moved to master already.  If it
has, revert is the only option.  If you noticed a mistake and want to
stop the commit from reaching master, you have to act fast enough that
the automated process will not make it progress into master.  If the
commit has been stopped by the automated process, you definitely do not
want to add a revert on top of it to staging and have the combined
commit+revert reach master.

Why don't we want commits breaking builds/regtests to reach master?  For
one thing, everything stops working for every developer, even people
working on entirely different parts of LilyPond.  If the catastrophe
stays confined to staging, people can still work on their personal
branches and repositories based on current master confidently.  They
have to wait until staging gets sorted out before they can _push_ again,
but their own work is not disrupted.

Apart from the temporary nuisance (for which the difference between
rewind/revert in staging does not really count: either fix will arrive
once it is made), "git bisect" is an important tool for finding problems
in history.  If parts of the master history do not even compile, that's
a total nuisance for figuring out when something started to go wrong.

So if our testing procedure gives us equal opportunity to revert or undo
a commit that causes the build to fail, choosing the undo means that the
resulting history is more useful for future detective work.  It also
makes less noise for things like "git blame".

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: dgutov@yandex.ru,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 21 Sep 2015 10:13:25 +0200
> 
> > Thanks, but would this mean that "git revert" for a commit pushed to
> > the "staging" branch would be wrong?  If so, can you explain why?
> 
> It depends on whether the commit has moved to master already.  If it
> has, revert is the only option.  If you noticed a mistake and want to
> stop the commit from reaching master, you have to act fast enough that
> the automated process will not make it progress into master.  If the
> commit has been stopped by the automated process, you definitely do not
> want to add a revert on top of it to staging and have the combined
> commit+revert reach master.

OK, but what would you do instead, then, in the case where the commit
is on "staged", but not yet on master?

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: dgutov@yandex.ru,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Mon, 21 Sep 2015 10:13:25 +0200
>> 
>> > Thanks, but would this mean that "git revert" for a commit pushed to
>> > the "staging" branch would be wrong?  If so, can you explain why?
>> 
>> It depends on whether the commit has moved to master already.  If it
>> has, revert is the only option.  If you noticed a mistake and want to
>> stop the commit from reaching master, you have to act fast enough that
>> the automated process will not make it progress into master.  If the
>> commit has been stopped by the automated process, you definitely do not
>> want to add a revert on top of it to staging and have the combined
>> commit+revert reach master.
>
> OK, but what would you do instead, then, in the case where the commit
> is on "staged", but not yet on master?

You fix staging.  Once the automated process finishes, it checks the
main repository and finds that the state of staging no longer contains
the commit it tested.  So it does not push to master (it does send out a
diagnostic Email).  The next time it runs, it picks up the fixed state
of staging and will hopefully finish.

At one point of time, our automated procedure did not do this "is my
tested commit still in staging" check before pushing to master.  That
was a lot more annoying: you noticed a problem, fixed it, and about an
hour later the unfixed state (which already had made it into the testing
procedure) still appeared in master, deadlocking the machinery because
now staging and master were out of synch.

This additional test right before pushing to master closed that time
window: once you successfully reset staging in the repository, you are
safe from the unfixed state getting pushed.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
> Date: Mon, 21 Sep 2015 10:27:19 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK, but what would you do instead, then, in the case where the commit
> > is on "staged", but not yet on master?
> 
> You fix staging.

Fix how?

This discussion is about the meaning of "rollback" for Git.  So what
I'm trying to figure out is whether there's some Git command other
than "revert" that the user who pushed a bad commit to "staged" should
perform to fix "staging".

If there's nothing to be done locally, then "revert" is still a good
interpretation of "rollback", even with the workflow you describe,
because in that workflow the user simply should not invoke any
rollbacks locally.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
>> Date: Mon, 21 Sep 2015 10:27:19 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > OK, but what would you do instead, then, in the case where the commit
>> > is on "staged", but not yet on master?
>> 
>> You fix staging.
>
> Fix how?

Remove the bad commit from the commit history.  That's what we are
talking about the whole time.

> This discussion is about the meaning of "rollback" for Git.  So what
> I'm trying to figure out is whether there's some Git command other
> than "revert" that the user who pushed a bad commit to "staged" should
> perform to fix "staging".

git reset --hard HEAD~1 in the simplest case.  Or git rebase -i with a
selective removal of commits.

> If there's nothing to be done locally,

With Git, you do everything locally first.  While it is possible to do
something like

git push origin +origin/staging~1:staging

and remove the top commit from the staging repository even without
involving the current tree, such repository-only operations are pretty
solidly outside of the reign of VC.

> then "revert" is still a good interpretation of "rollback", even with
> the workflow you describe, because in that workflow the user simply
> should not invoke any rollbacks locally.

But the usual thing is to "rollback", namely establish the _commit_
state from before the bad commit, when encountering a staging-only
problem.

Git's own development tree has "next", another branch which is
frequently being reset rather than have anything reverted in it.  Other
projects have similar "tryout" branches.  When you are using branches
for proposing patches (like the review tool Gerrit does), you are
supposed to _amend_ your proposals so that they look like they've been
done correctly right from the start, rather than adding fixes on top.
Again, this is rollback territory (or more frequently, git rebase -i
territory).  It is only both public and non-ephemeral branches which
should not see history changes.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
> Date: Mon, 21 Sep 2015 10:58:22 +0200
> 
> >> > OK, but what would you do instead, then, in the case where the commit
> >> > is on "staged", but not yet on master?
> >> 
> >> You fix staging.
> >
> > Fix how?
> 
> Remove the bad commit from the commit history.  That's what we are
> talking about the whole time.
> 
> > This discussion is about the meaning of "rollback" for Git.  So what
> > I'm trying to figure out is whether there's some Git command other
> > than "revert" that the user who pushed a bad commit to "staged" should
> > perform to fix "staging".
> 
> git reset --hard HEAD~1 in the simplest case.  Or git rebase -i with a
> selective removal of commits.

Followed by a push, I presume?  IOW, the 'staging" branch permits
non-FF pushes?

> > then "revert" is still a good interpretation of "rollback", even with
> > the workflow you describe, because in that workflow the user simply
> > should not invoke any rollbacks locally.
> 
> But the usual thing is to "rollback", namely establish the _commit_
> state from before the bad commit, when encountering a staging-only
> problem.
> 
> Git's own development tree has "next", another branch which is
> frequently being reset rather than have anything reverted in it.  Other
> projects have similar "tryout" branches.  When you are using branches
> for proposing patches (like the review tool Gerrit does), you are
> supposed to _amend_ your proposals so that they look like they've been
> done correctly right from the start, rather than adding fixes on top.
> Again, this is rollback territory (or more frequently, git rebase -i
> territory).  It is only both public and non-ephemeral branches which
> should not see history changes.

So I guess we will have to provide a way for the user to tell VC which
branch is of the "revert" type and which is of the "reset" type?

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
>> Date: Mon, 21 Sep 2015 10:58:22 +0200
>> 
>> >> > OK, but what would you do instead, then, in the case where the commit
>> >> > is on "staged", but not yet on master?
>> >> 
>> >> You fix staging.
>> >
>> > Fix how?
>> 
>> Remove the bad commit from the commit history.  That's what we are
>> talking about the whole time.
>> 
>> > This discussion is about the meaning of "rollback" for Git.  So what
>> > I'm trying to figure out is whether there's some Git command other
>> > than "revert" that the user who pushed a bad commit to "staged" should
>> > perform to fix "staging".
>> 
>> git reset --hard HEAD~1 in the simplest case.  Or git rebase -i with a
>> selective removal of commits.
>
> Followed by a push, I presume?  IOW, the 'staging" branch permits
> non-FF pushes?

That would be the ideal case (set up via repository setting and a hook
that selectively allows some branches to have non-FF pushes and some
not).  Savannah is not set up this way, so you just delete the branch
and push a new one.

>> Git's own development tree has "next", another branch which is
>> frequently being reset rather than have anything reverted in it.
>> Other projects have similar "tryout" branches.  When you are using
>> branches for proposing patches (like the review tool Gerrit does),
>> you are supposed to _amend_ your proposals so that they look like
>> they've been done correctly right from the start, rather than adding
>> fixes on top.  Again, this is rollback territory (or more frequently,
>> git rebase -i territory).  It is only both public and non-ephemeral
>> branches which should not see history changes.
>
> So I guess we will have to provide a way for the user to tell VC which
> branch is of the "revert" type and which is of the "reset" type?

I don't think that it's the job of VC to make the user follow some
policy it tries guessing.  It's the user who needs to specify whether he
wants a revert or a reset.  I may perfectly well place a revert in the
staging branch when the original commit is already in master.  But VC
has no business snooping around in other branches in order to do some
DWIM stuff depending on project-local policies.

-- 
David Kastrup

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

[Bastian Beischer]

[-- Attachment #1: Type: text/plain, Size: 4430 bytes --]

Dear all,

I'm not an emacs developer but I'd like to jump in:

As you may know, in git, when a commit is made it consists of these things:

- A complete of snapshot of the file structure of the entire repository and
all file contents
- The commit message, commit time + author time, commiting person
- The SHA1 identifier of the previous commit(s) (there can be multiple in
case of a merge commit)

All of these things enter into the SHA1 identifier of the commit! git has
the tools to change any of the above a posteriori, but it's vital to
understand that any such modification, even if it's just a typo in the
commit message will modify the SHA1 of the commit. The old commit with it's
identifier still exists, but it's 'dangling' i.e. it's typically not part
of the local branch you are working in any more.

Any references to the old identifier of the commit become invalid at that
point!

As long as any such discarded commit was not pushed to a public repository,
it's generally considered fine to do these modifications to your liking.

However, once a commit is pushed out to a public place the situation
changes. People may be using the old ID to refer to that specific commit,
whether you know it or not.

Then, whether you want to allow 'rewriting history' depends entirely on the
conventions in your project - there's no general rule. In emacs you may say
it's OK, even recommened, to modify the staging branch a posteriori in case
a mistake was made. Therefore, it's in general impossible to do the right
thing without knowing the project policy.

In case rewriting history is not possible or wanted, git revert is there to
help you: It simply creates a new commit which applies the reverse patch
with an appropriate commit messate, that's all.

I urge you to read these:

- http://git-scm.com/book/en/v2/Git-Internals-Git-References
- man git rebase (section "RECOVERING FROM UPSTREAM REBASE")
- man git tag (section "DISCUSSION - On Re-tagging")

Best
Bastian


On Mon, Sep 21, 2015 at 11:42 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: David Kastrup <dak@gnu.org>
> > Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
> > Date: Mon, 21 Sep 2015 10:58:22 +0200
> >
> > >> > OK, but what would you do instead, then, in the case where the
> commit
> > >> > is on "staged", but not yet on master?
> > >>
> > >> You fix staging.
> > >
> > > Fix how?
> >
> > Remove the bad commit from the commit history.  That's what we are
> > talking about the whole time.
> >
> > > This discussion is about the meaning of "rollback" for Git.  So what
> > > I'm trying to figure out is whether there's some Git command other
> > > than "revert" that the user who pushed a bad commit to "staged" should
> > > perform to fix "staging".
> >
> > git reset --hard HEAD~1 in the simplest case.  Or git rebase -i with a
> > selective removal of commits.
>
> Followed by a push, I presume?  IOW, the 'staging" branch permits
> non-FF pushes?
>
> > > then "revert" is still a good interpretation of "rollback", even with
> > > the workflow you describe, because in that workflow the user simply
> > > should not invoke any rollbacks locally.
> >
> > But the usual thing is to "rollback", namely establish the _commit_
> > state from before the bad commit, when encountering a staging-only
> > problem.
> >
> > Git's own development tree has "next", another branch which is
> > frequently being reset rather than have anything reverted in it.  Other
> > projects have similar "tryout" branches.  When you are using branches
> > for proposing patches (like the review tool Gerrit does), you are
> > supposed to _amend_ your proposals so that they look like they've been
> > done correctly right from the start, rather than adding fixes on top.
> > Again, this is rollback territory (or more frequently, git rebase -i
> > territory).  It is only both public and non-ephemeral branches which
> > should not see history changes.
>
> So I guess we will have to provide a way for the user to tell VC which
> branch is of the "revert" type and which is of the "reset" type?
>
>


-- 
Bastian Beischer
RWTH Aachen University of Technology

@RWTH Aachen
Office: 28 C 203
Phone: +49-241-80-27205
E-mail: beischer@physik.rwth-aachen.de
Address: I. Physikalisches Institut B, Sommerfeldstr. 14, D-52074 Aachen

@CERN
Office: Bdg 32-4-B12
Phone: +41-22-76-75750
E-mail: bastian.beischer@cern.ch
Address: CERN, CH-1211 Geneve 23

[-- Attachment #2: Type: text/html, Size: 6765 bytes --]

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I suggest that people (1) make a new VC command for undo-last-checking,
perhaps with a different name to move it out of the way, the (2) implement
it on whichever backends they can.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Stephen J. Turnbull]

Richard Stallman writes:

 > I suggest that people (1) make a new VC command for undo-last-checking,
 > perhaps with a different name to move it out of the way, the (2) implement
 > it on whichever backends they can.

The question is how many such commands do we need.  In most VCSes, it
is hard[1] to actually remove commits, and the only thing that can be
done is to apply a reversed patch (git calls this "revert").  In
others, there is a command to remove commits from a branch (git calls
it "reset", and it's nondestructive; Mercurial calls it "strip", and
it seems to be destructive).

However, resetting a published branch is likely to cause all kinds of
trouble when others pull and merge the reset branch with their own
branches, and Eli suggests a third, DWIMish approach, which is to
reset if the branch isn't public and to revert if it is.

Footnotes: 
[1]  You may need admin privileges or the like, or access to the
repository host, etc.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In CVS, removing a commit is easy and nonproblematic.  So this command
could support CVS.  If it supports only one back end, that's better
than none.

If some other back ends can be supported by applying the reversed change,
that might be better than not supporting it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

> In CVS, removing a commit is easy and nonproblematic.  So this command
> could support CVS.  If it supports only one back end, that's better
> than none.
>
> If some other back ends can be supported by applying the reversed change,
> that might be better than not supporting it.

Adding the reverse change to the history is quite different from
removing the change from the history. IMHO it would be wrong to
implement a command that does one thing or another depending on the
backend.

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

[Eli Zaretskii]

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

The only other choice is not to implement it for modern VCSes at all,
which IMO would be a pity.

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

[David Kastrup]

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

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

[Stephen J. Turnbull]

Eli Zaretskii writes:

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

Those users are *precisely* the ones who would be offended by DWIM.
If you're going to add a command because people who know what they're
doing and have advanced needs, Emacs really shouldn't be second-
guessing them.

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 23 Sep 2015 17:28:29 +0900
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Eli Zaretskii writes:
> 
>  > 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.
> 
> Those users are *precisely* the ones who would be offended by DWIM.

<Shrug> I'm one such user, and I'd appreciate such DWIM very much.  As
long as the command doesn't push upstream, such DWIM is IMO much
better than erroring out and asking me to invoke the other command by
hand.

But again, I'm not going to argue.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Adding the reverse change to the history is quite different from
  > removing the change from the history. IMHO it would be wrong to
  > implement a command that does one thing or another depending on the
  > backend.

I disagree with that general statement.

But even if that were true in general, it isn't really applicable here
because this command will ask for confirmation.
In the process, it can say which way it will do the job.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Dmitry Gutov]

On 09/23/2015 01:02 AM, Richard Stallman wrote:

> In CVS, removing a commit is easy and nonproblematic.  So this command
> could support CVS.  If it supports only one back end, that's better
> than none.

Could you point out that exact "easy and nonproblematic" way? Is it the 
admin-privilege command? Or adding a new commit that would revert 
changes in the previous one?

> If some other back ends can be supported by applying the reversed change,
> that might be better than not supporting it.

Maybe we should have both "rollback" and "revert" commands. Multiple 
backends seem to distinguish them already.

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

[Eli Zaretskii]

> Cc: eliz@gnu.org, dak@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 23 Sep 2015 08:36:44 +0300
> 
> Maybe we should have both "rollback" and "revert" commands. Multiple 
> backends seem to distinguish them already.

That's a possibility, yes.  Except that "vc-revert" might not be a
good name, because some VCSes (at least svn and bzr) have "revert"
commands that do something very different.

Or we could conflate both commands into a single vc-rollback, with the
second variety triggered by the prefix argument.

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

[Stefan Monnier]

> Maybe we should have both "rollback" and "revert" commands.  Multiple
> backends seem to distinguish them already.

They are indeed very different, so it makes a lot of sense to have them
as completely separate commands.

The "revert" (which IIUC just installs a new change which undoes the
effect of some earlier change) can mostly be implemented in
a backend-independent way.

But the "rollback" (which IIUC can destructively remove an previous
existing commit, I guess I'd call it "uncommit") is a lot more
problematic, since various backends support it in very different ways
with very different limitations.  Generalizing the "Amend:" support of
vc-git.el to other backends would probably cover 99% of the use cases.

If you feel it's really important that user be able to delete a revision
from within Emacs, why not provide a vc-rcs-delete-commits command in
vc-rcs.el?  That would be a lot simpler to implement and wouldn't force us
to come up with some weird pseudo-generic functionality that might end
up not even supporting 100% of RCS's use cases.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 23 Sep 2015 09:26:56 -0400
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, dak@gnu.org, eliz@gnu.org,
> 	rms@gnu.org, emacs-devel@gnu.org
> 
> If you feel it's really important that user be able to delete a revision
> from within Emacs, why not provide a vc-rcs-delete-commits command in
> vc-rcs.el?

Because it's also supported by CVS?

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

[Stefan Monnier]

>> If you feel it's really important that user be able to delete a revision
>> from within Emacs, why not provide a vc-rcs-delete-commits command in
>> vc-rcs.el?
> Because it's also supported by CVS?

So what.  I guess it's also supported by git's rebase (IIUC they call it
"squash") and for all I know bzr-rewrite might also support it.

Of course "it" might not mean quite the same thing in those different
situations, so coming up with a generic command which can make sense for
most backends might not be as simple as it seems.

And that for something that is used extremely rarely.


        Stefan

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> If you feel it's really important that user be able to delete a revision
>>> from within Emacs, why not provide a vc-rcs-delete-commits command in
>>> vc-rcs.el?
>> Because it's also supported by CVS?
>
> So what.  I guess it's also supported by git's rebase (IIUC they call it
> "squash")

Squashing is combining the changes of two commits into a single commit
with a combined commit message.  That's not really "deleting" in any
sense of the word.

-- 
David Kastrup

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

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> If you feel it's really important that user be able to delete a revision
>>>> from within Emacs, why not provide a vc-rcs-delete-commits command in
>>>> vc-rcs.el?
>>> Because it's also supported by CVS?
>>
>> So what.  I guess it's also supported by git's rebase (IIUC they call it
>> "squash")
>
> Squashing is combining the changes of two commits into a single commit
> with a combined commit message.  That's not really "deleting" in any
> sense of the word.

But that's what rcs -o does (except that it always throws away the log
message).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The "revert" (which IIUC just installs a new change which undoes the
 > effect of some earlier change) can mostly be implemented in
 > a backend-independent way.

As mentioned, that's git terminology; other VCSes use that name for
different operations: hg and bzr check out individual files as of some
revision -- no commit takes place.  For the effect of "git revert", I
believe hg uses "backout", bzr uses a "merge" variant.

 > But the "rollback" (which IIUC can destructively remove an previous
 > existing commit, I guess I'd call it "uncommit")

git has no command to destructively remove commits (except gc --prune,
which by default gives a 60-day grace period IIRC).  "git reset"
simply move the HEAD pointer, and the current branch head if there is
one.

In hg, "rollback" and "strip" are destructive (the commit no longer
exists in the repo), with the caveat that "strip" saves a patch bundle
that can be restored.  (I think it contains enough information to
reproduce the commit.)  bzr "uncommit" appears to be destructive,
although if you save off the revids (not the revno!), you may be able
to merge it back using that information.  (Untested; on consideration,
it's likely that "uncommit" alters the DAG so that the commits cannot
be recovered.)

 > is a lot more problematic, since various backends support it in
 > very different ways with very different limitations.  Generalizing
 > the "Amend:" support of vc-git.el to other backends would probably
 > cover 99% of the use cases.

Mercurial has "commit --amend", similar to the command of the same
name of git's.  For bzr, I would guess you need to uncommit then
commit again (dunno, but I couldn't find a command documented in bzr
help, although Google finds RFEs for "commit --amend" and
"recommit").  LP has a bug with a nice description of the workflow for
bzr: https://bugs.launchpad.net/bzr/+bug/507529.

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

[Dmitry Gutov]

On 09/23/2015 04:26 PM, Stefan Monnier wrote:

> The "revert" (which IIUC just installs a new change which undoes the
> effect of some earlier change) can mostly be implemented in
> a backend-independent way.

Yep. But then it won't be the "rollback" command that's been requested.

> But the "rollback" (which IIUC can destructively remove an previous
> existing commit, I guess I'd call it "uncommit") is a lot more
> problematic, since various backends support it in very different ways
> with very different limitations.

Ok, if you're sure about that.

> Generalizing the "Amend:" support of
> vc-git.el to other backends would probably cover 99% of the use cases.

We'd have to see more opinions on this - e.g. the use cases for 
vc-uncommit and vc-amend that I can imagine would be slightly different.

Regarding "Amend:", we might want to start with taking care of the main 
annoyance (IME): when there are no changes to files, I can't easily 
amend the current commit with the purpose of changing its message.

How would handle that? Make `C-u C-x v v' ignore the 'up to date' 
status? Create a separate command for "amend"?

> If you feel it's really important that user be able to delete a revision
> from within Emacs, why not provide a vc-rcs-delete-commits command in
> vc-rcs.el?

I don't feel that anything related to RCS can be classified as "really 
important". It would be useful if it's implemented in modern backends. 
But rollback isn't hard to do by hand anyway.

> That would be a lot simpler to implement and wouldn't force us
> to come up with some weird pseudo-generic functionality that might end
> up not even supporting 100% of RCS's use cases.

Naturally: if the semantics are that different between RCS and Git, we 
shouldn't try to force both into something unnatural.

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

[Stefan Monnier]

> How would handle that? Make `C-u C-x v v' ignore the 'up to date' status?

Yes, M-x vc-commit RET should definitely ignore the "up to date" status.


        Stefan

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

[Dmitry Gutov]

On 09/23/2015 06:21 PM, Stefan Monnier wrote:

> Yes, M-x vc-commit RET should definitely ignore the "up to date" status.

By vc-commit, do you mean vc-next-action, or a new command?

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

[Stefan Monnier]

>> Yes, M-x vc-commit RET should definitely ignore the "up to date" status.
> By vc-commit, do you mean vc-next-action, or a new command?

Nowadays (as in "with modern VCS"), vc-next-action can't do much
beside commit, and `vc-next-action' is also the only command which
can do "commit".

So, yes, I mean a new command (which should mostly supercede
vc-next-action).


        Stefan

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

[Dmitry Gutov]

On 09/23/2015 08:33 PM, Stefan Monnier wrote:
>>> Yes, M-x vc-commit RET should definitely ignore the "up to date" status.
>> By vc-commit, do you mean vc-next-action, or a new command?
>
> Nowadays (as in "with modern VCS"), vc-next-action can't do much
> beside commit, and `vc-next-action' is also the only command which
> can do "commit".

It also performs that weird step: "If every file in the VC fileset is 
not registered for version control, register the fileset (but don't 
commit)", aborting if some of the files in the fileset are unregistered 
and others are registered.

It would make sense to remove it (and commit all selected files), but it 
would be nice to know what prompted its existence in the first place.

This could also be dropped (we have a separate command for it):

"For a centralized version control system, if any work file in the VC 
fileset is out of date, offer to update the fileset."

> So, yes, I mean a new command (which should mostly supercede
> vc-next-action).

The section dedicated to "For old-style locking-based version control 
systems" in vc-next-action's docstring is more convoluted. As long as 
we're dedicated to supporting them, I'm not sure what change would be 
appropriate.

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

[Stefan Monnier]

> It also performs that weird step: "If every file in the VC fileset is not
> registered for version control, register the fileset (but don't commit)",
> aborting if some of the files in the fileset are unregistered and others
> are registered.

Right.  From a modern VCS's point of view, I think vc-next-action just
doesn't make any sense, and trying to be more clever at guessing what
the user intended won't get us very far.

That's why I think we'd be better off providing vc-commit.  AFAIK, all
other operations provided by vc-next-action can be reached via other
commands, so the only new command that's really needed is vc-commit.

Then we can just keep vc-next-action for those old VCSes or for those
rare users who like it.

> The section dedicated to "For old-style locking-based version control
> systems" in vc-next-action's docstring is more convoluted. As long as we're
> dedicated to supporting them, I'm not sure what change would be appropriate.

The change I'm hinting at is to declare vc-next-action obsolete, tho
I know Eric won't like it.  But even if we want to keep it, I think it's
important, from a design point of view, to make sure that it's never
*necessary* to use vc-next-action.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  "Stephen J. Turnbull" <stephen@xemacs.org>,  eliz@gnu.org,  dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 30 Sep 2015 00:53:51 -0400
> 
> > It also performs that weird step: "If every file in the VC fileset is not
> > registered for version control, register the fileset (but don't commit)",
> > aborting if some of the files in the fileset are unregistered and others
> > are registered.
> 
> Right.  From a modern VCS's point of view, I think vc-next-action just
> doesn't make any sense, and trying to be more clever at guessing what
> the user intended won't get us very far.
> 
> That's why I think we'd be better off providing vc-commit.  AFAIK, all
> other operations provided by vc-next-action can be reached via other
> commands, so the only new command that's really needed is vc-commit.
> 
> Then we can just keep vc-next-action for those old VCSes or for those
> rare users who like it.

That'd be fine with me, at least.

But I still wonder why it won't be better to keep vc-next-action for
supporting a simple CVS-like workflow with dVCSes as well.  In such a
workflow, the only additional step is "push".  We can even ignore
"push", leaving it to the user, in which case the order of operations
in such a simple workflow is exactly the same as with RCS or CVS.  Why
not let people migrate gently, instead of abruptly removing all the
basics they've learned?

> > The section dedicated to "For old-style locking-based version control
> > systems" in vc-next-action's docstring is more convoluted. As long as we're
> > dedicated to supporting them, I'm not sure what change would be appropriate.
> 
> The change I'm hinting at is to declare vc-next-action obsolete

That's too radical, I think.  Keeping vc-next-action only for the
older VCSes doesn't mean it's obsolete in any way, because "obsolete"
means "subject to removal soon", which is not the case here.

> But even if we want to keep it, I think it's important, from a
> design point of view, to make sure that it's never *necessary* to
> use vc-next-action.

I think we are already there: vc-next-action invokes commands that are
all available separately, no?

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

[Stefan Monnier]

> I think we are already there: vc-next-action invokes commands that are
> all available separately, no?

No, that's my point: you currently can't commit changes without using
vc-next-action.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  rms@gnu.org,  stephen@xemacs.org,  dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 30 Sep 2015 04:37:27 -0400
> 
> > I think we are already there: vc-next-action invokes commands that are
> > all available separately, no?
> 
> No, that's my point: you currently can't commit changes without using
> vc-next-action.

You mean, the only problem is give vc-checkin an interactive spec (and
maybe add an alias vc-commit)?

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

[Dmitry Gutov]

On 09/30/2015 11:52 AM, Eli Zaretskii wrote:

> You mean, the only problem is give vc-checkin an interactive spec (and
> maybe add an alias vc-commit)?

And vc-steal-lock, and maybe "unlock"? I can't find the part that 
implements the "If every file is locked by you and unchanged, unlock 
them" part of the docstring.

That sounds like a lot of micromanagement for users of backends with 
locking, unfortunately.

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

[Stefan Monnier]

> That sounds like a lot of micromanagement for users of backends with
> locking, unfortunately.

How many of those users actually use locking?


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I still use RCS.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Dmitry Gutov]

On 10/01/2015 05:22 AM, Richard Stallman wrote:

> I still use RCS.

Please elaborate: do you really benefit from the ability to lock the 
file in advance?

As one option, we could implement the RCS `checkin' command to simply 
check whether lock exists, and if not, try to steal it. And give up if 
that fails.

Then the VC API wouldn't have to know about locking at all.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I still use RCS.

  > Please elaborate: do you really benefit from the ability to lock the 
  > file in advance?

No, I didn't know about that feature.  The message said "locking",
so I tought it meant locking by checkout.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Dmitry Gutov]

On 10/02/2015 05:27 AM, Richard Stallman wrote:

>    > Please elaborate: do you really benefit from the ability to lock the
>    > file in advance?
>
> No, I didn't know about that feature.  The message said "locking",
> so I tought it meant locking by checkout.

See e.g. vc-steal-lock. It's only used in vc-next-action.

If you don't use RCS in a multi-level environment, same as Eli, and 
nobody else does, we don't really need that locking feature, and so we 
don't need vc-next-action to "steal the lock" as a separate step. We 
don't need that function, and we don't need the `steal-lock' backend 
command.

If RCS demands that a file is locked to the current user before 
committing (I'm not sure), vc-rcs-checkin could do that.

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

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> If RCS demands that a file is locked to the current user before committing
> (I'm not sure), vc-rcs-checkin could do that.

You can configure RCS to do non-strict locking (see rcs -U).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, eliz@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 2 Oct 2015 09:37:58 +0300
> 
> If RCS demands that a file is locked to the current user before 
> committing (I'm not sure)

It does, by default.  (The default can be changed by the user, if she
wants.)

> vc-rcs-checkin could do that.

AFAICS, it already does.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If you don't use RCS in a multi-level environment, same as Eli, and 
  > nobody else does, we don't really need that locking feature, and so we 
  > don't need vc-next-action to "steal the lock" as a separate step. We 
  > don't need that function, and we don't need the `steal-lock' backend 
  > command.

We cannot conclude that a feature is unused
from a discussion on this list.  That requires polling the list.

C-x v v for RCS works fine.  Likewise for CVS.  We will not change
those behaviors.

We can change what it does for git, if git users like the change.
That is something we can tell from discussion on this list.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, eliz@gnu.org, stephen@xemacs.org,
> 	dak@gnu.org, emacs-devel@gnu.org
> Date: Thu, 01 Oct 2015 22:27:49 -0400
> 
>   > > I still use RCS.
> 
>   > Please elaborate: do you really benefit from the ability to lock the 
>   > file in advance?
> 
> No, I didn't know about that feature.  The message said "locking",
> so I tought it meant locking by checkout.

That's about what it does, indeed.  But you will never see any effects
of locking if you don't share the repository with another user.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That's about what it does, indeed.  But you will never see any effects
  > of locking if you don't share the repository with another user.

That is true, but someone asked if people use RCS, and using RCS by
default means using locking.

In fact, I do use RCS with files edited by other users.
With locking.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Eli Zaretskii]

> Cc: rms@gnu.org, stephen@xemacs.org, dak@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 30 Sep 2015 14:35:39 +0300
> 
> On 09/30/2015 11:52 AM, Eli Zaretskii wrote:
> 
> > You mean, the only problem is give vc-checkin an interactive spec (and
> > maybe add an alias vc-commit)?
> 
> And vc-steal-lock, and maybe "unlock"? I can't find the part that 
> implements the "If every file is locked by you and unchanged, unlock 
> them" part of the docstring.

Maybe we should simply leave the locking VCSes out of this.  People
who use those back-ends have used vc-next-action for a long time, so I
guess they won't really need vc-steal-lock.

IOW, let's make vc-checkin interactive so that it assumes the files
are not locked by someone else.  WDYT?

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

[Dmitry Gutov]

On 09/30/2015 05:00 PM, Eli Zaretskii wrote:

> Maybe we should simply leave the locking VCSes out of this.  People
> who use those back-ends have used vc-next-action for a long time, so I
> guess they won't really need vc-steal-lock.

Well, there are not too many key bindings we can use. Being able to bind 
vc-checkin to `C-x v v' instead of `vc-next-action' would be nice.

IMO, it's the main argument in favor of deprecating the latter command.

> IOW, let's make vc-checkin interactive so that it assumes the files
> are not locked by someone else.  WDYT?

Do we make a separate binding for it?

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 05:34:31 +0300
> 
> On 09/30/2015 05:00 PM, Eli Zaretskii wrote:
> 
> > Maybe we should simply leave the locking VCSes out of this.  People
> > who use those back-ends have used vc-next-action for a long time, so I
> > guess they won't really need vc-steal-lock.
> 
> Well, there are not too many key bindings we can use. Being able to bind 
> vc-checkin to `C-x v v' instead of `vc-next-action' would be nice.

AFAICS, "C-x v c" and "C-x v C" are both available, and should be good
candidates for vc-checkin, I think.

> IMO, it's the main argument in favor of deprecating the latter command.
> 
> > IOW, let's make vc-checkin interactive so that it assumes the files
> > are not locked by someone else.  WDYT?
> 
> Do we make a separate binding for it?

Yes, I think so.  It's an important VC command.

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

[Dmitry Gutov]

On 10/01/2015 10:06 AM, Eli Zaretskii wrote:

>>> Maybe we should simply leave the locking VCSes out of this.  People
>>> who use those back-ends have used vc-next-action for a long time, so I
>>> guess they won't really need vc-steal-lock.
> AFAICS, "C-x v c" and "C-x v C" are both available, and should be good
> candidates for vc-checkin, I think.

Thinking back to your argument that "For a centralized version control 
system, if any work file in the VC fileset is out of date, offer to 
update the fileset" still makes sense, it sounds like we should use a 
more complex `vc-commit' that would incorporate that step, as well as 
the checkin action itself.

Further, creating a new binding for `vc-commit' looks like a 
half-measure. If we intend it to be used more, it should occupy the 
easier to hit key sequence (C-x v v).

If we agree on that, there are several options for vc-next-action. 
Either find it a new binding, or remove its binding altogether a take 
care of locking backends some other way (either with a dedicated 
vc-steal-lock command, or by locking right before committing, like 
explained previously).

To my (obviously) limited knowledge, RMS is the only user of a locking 
backend, and so far he hasn't answered the pertinent question about his 
workflow.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 22:43:20 +0300
> 
> Further, creating a new binding for `vc-commit' looks like a 
> half-measure. If we intend it to be used more, it should occupy the 
> easier to hit key sequence (C-x v v).

v and c are neighbors, so I don't see why "C-x v c" would be hard.

> If we agree on that, there are several options for vc-next-action. 
> Either find it a new binding, or remove its binding altogether a take 
> care of locking backends some other way

I ask once again why not make vc-next-action support some simple
workflow with modern VCSes.

> To my (obviously) limited knowledge, RMS is the only user of a locking 
> backend, and so far he hasn't answered the pertinent question about his 
> workflow.

If by "locking VCS" you mean RCS, then I use it from time to time.

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

[Dmitry Gutov]

On 10/01/2015 10:59 PM, Eli Zaretskii wrote:
> v and c are neighbors, so I don't see why "C-x v c" would be hard.

It's not hard, it's harder. Again, if `vc-commit' is going to be the 
preferred command, it should use the better binding.

Arguing otherwise is discouraging, and it's a good example of why focus 
on backward compatibility saps mental energy. Would you prefer I don't 
work on this change at all?

> I ask once again why not make vc-next-action support some simple
> workflow with modern VCSes.

That's very vague.

>> To my (obviously) limited knowledge, RMS is the only user of a locking
>> backend, and so far he hasn't answered the pertinent question about his
>> workflow.
>
> If by "locking VCS" you mean RCS, then I use it from time to time.

Could you answer that question, then?

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 23:06:14 +0300
> 
> On 10/01/2015 10:59 PM, Eli Zaretskii wrote:
> > v and c are neighbors, so I don't see why "C-x v c" would be hard.
> 
> It's not hard, it's harder. Again, if `vc-commit' is going to be the 
> preferred command, it should use the better binding.

The difference is too small to justify breaking old habits, IMO.

> Arguing otherwise is discouraging, and it's a good example of why focus 
> on backward compatibility saps mental energy. Would you prefer I don't 
> work on this change at all?

No, I would prefer that you'd be more willing to compromise at times.

> > I ask once again why not make vc-next-action support some simple
> > workflow with modern VCSes.
> 
> That's very vague.

I described up-thread what I had in mind in more detail: a CVS-like
workflow.

> >> To my (obviously) limited knowledge, RMS is the only user of a locking
> >> backend, and so far he hasn't answered the pertinent question about his
> >> workflow.
> >
> > If by "locking VCS" you mean RCS, then I use it from time to time.
> 
> Could you answer that question, then?

I thought I already did: I always use RCS for files I maintain myself,
so other users are not involved, and locking is a no-op.

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

[Dmitry Gutov]

On 10/01/2015 11:12 PM, Eli Zaretskii wrote:

>> It's not hard, it's harder. Again, if `vc-commit' is going to be the
>> preferred command, it should use the better binding.
>
> The difference is too small to justify breaking old habits, IMO.

I would rather work on something else than end up with a suboptimal 
solution. But we don't need to introduce it in Emacs 25, I was going to 
delay this until after the next release anyway.

> No, I would prefer that you'd be more willing to compromise at times.

At times, I am, but not in this instance. And Stefan also stated the 
preference for vc-next-action to go away.

> I described up-thread what I had in mind in more detail: a CVS-like
> workflow.

Please link to that message.

But if we were to do that, what's the need for vc-commit?

>>> If by "locking VCS" you mean RCS, then I use it from time to time.
>>
>> Could you answer that question, then?
>
> I thought I already did: I always use RCS for files I maintain myself,
> so other users are not involved, and locking is a no-op.

So, would you say that support for locking is not important anymore? Or 
should we ask someone else?

If you'd like the support for locking to stay (and not only as a part of 
an obsolete vc-next-action without binding), could you poll some other 
users with the same question?

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

[Alan Mackenzie]

Hello Eli and Dmitry.

On Thu, Oct 01, 2015 at 11:38:08PM +0300, Eli Zaretskii wrote:
> > Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
> >  emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Thu, 1 Oct 2015 23:22:40 +0300

> > On 10/01/2015 11:12 PM, Eli Zaretskii wrote:

> > And Stefan also stated the preference for vc-next-action to go away.

> So let's ask others if they are willing to see vc-next-action go
> away.  Richard, Alan, what say you?

I'm not the best person to ask, since I don't use it.  I've always
disliked the dwimmy aspect of vc-next-action - I prefer each individual
action to have its own distinct keybinding.  The thing about VCSs is that
many actions done with them are irrevocable, or nearly so - there's no
undo for them.  Also I think C-x v v would be very easy to type by
mistake - an accidental auto-repeat when typing the v a bit slowly would
do it, so that's another argument against it for me (or at least it was
when I disabled vc a decade or so ago).  vc-next-action doesn't have a
yes-or-no-p in it, does it?

Also, I think using vc would be an extra learning burden on top of that
of learning the base VCS, not an alternative to it.  Certainly knowing vc
did not enable Richard to access a git repository some months ago.

But I do accept that vc is probably faster to use than command line
commands, particularly if you're using it a lot.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dmitry Gutov]

On 10/02/2015 12:01 AM, Alan Mackenzie wrote:

> Also I think C-x v v would be very easy to type by
> mistake - an accidental auto-repeat when typing the v a bit slowly would
> do it, so that's another argument against it for me (or at least it was
> when I disabled vc a decade or so ago).  vc-next-action doesn't have a
> yes-or-no-p in it, does it?

The binding is not under discussion, the semantics of the command are.

But removing `C-x v v' from the global map is a valid approach, as long 
as vc-dir-mode-map still has it.

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

[Dmitry Gutov]

On 10/01/2015 11:38 PM, Eli Zaretskii wrote:

> The degree of sub-optimality is so small here that I can hardly see
> it.

The degree of habit-breaking must be tiny as well. Like you say, the 
keys are close.

> I didn't say more than I said above.  If "CVS-like workflow" is not
> detailed enough, I can elaborate.

We already have vc-next-action working for Git. And if you mean a 
bound-branch-like workflow, then as we've discussed a while ago, 
implementing it is not tenable.

> Adding vc-commit was Stefan's idea, so he should answer that.  I just
> said that if having that command will make someone happier, it's an
> easy job.

I'm pretty sure that no one here just wants to have a command that has a 
"checkin" or "commit" in its name.

For me, having a singular purpose makes it easier to implement features 
like "amend" on top of it. When called with a prefix, for instance.

It would make it easier to use as well.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, Alan Mackenzie <acm@muc.de>,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 2 Oct 2015 00:01:24 +0300
> 
> > I didn't say more than I said above.  If "CVS-like workflow" is not
> > detailed enough, I can elaborate.
> 
> We already have vc-next-action working for Git.

Then I see no reason for vc-next-action to go away.

> And if you mean a bound-branch-like workflow, then as we've
> discussed a while ago, implementing it is not tenable.

I got the point back then, so no, I don't mean that.

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

[Dmitry Gutov]

On 10/02/2015 09:32 AM, Eli Zaretskii wrote:

> Then I see no reason for vc-next-action to go away.

To pave the way for a better replacement.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 2 Oct 2015 09:41:43 +0300
> 
> On 10/02/2015 09:32 AM, Eli Zaretskii wrote:
> 
> > Then I see no reason for vc-next-action to go away.
> 
> To pave the way for a better replacement.

If the replacement just have a different name, but otherwise behaves
the same or very similar, no objections from me.

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

[Stefan Monnier]

>> > I think we are already there: vc-next-action invokes commands that are
>> > all available separately, no?
>> No, that's my point: you currently can't commit changes without using
>> vc-next-action.
> You mean, the only problem is give vc-checkin an interactive spec (and
> maybe add an alias vc-commit)?

Pretty much.  And give it a key-binding.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > You mean, the only problem is give vc-checkin an interactive spec (and
  > > maybe add an alias vc-commit)?

  > Pretty much.  And give it a key-binding.

Making it interactive is one step; giving it a key binding
is another step.  I am not necessarily against the second step
but the first step does not require the second.

I often use C-x v v for vc-next-action.  Please do not delete that
binding.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But I still wonder why it won't be better to keep vc-next-action for
  > supporting a simple CVS-like workflow with dVCSes as well.  In such a
  > workflow, the only additional step is "push".

It could ask "Push all commits now?" after each commit.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

When we switched to bzr, I stopped using vc-next-action for commits,
because even the simplest change involved two files: a source file
and a ChangeLog file.

But now that we don't maintain ChangeLog files in the repository,
that is no longer true.  Why doesn't vc-next-action succeed in
determining that what you want to do is a commit?
  

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Stefan Monnier]

> that is no longer true.  Why doesn't vc-next-action succeed in
> determining that what you want to do is a commit?
  
It does.  It's just that it doesn't determine that what you want to do
is something else.  So let's stop pretending and let's just call it
"vc-commit".


        Stefan "not 100% serious"

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  stephen@xemacs.org,  dak@gnu.org,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 01 Oct 2015 23:34:06 -0400
> 
> > that is no longer true.  Why doesn't vc-next-action succeed in
> > determining that what you want to do is a commit?
>   
> It does.  It's just that it doesn't determine that what you want to do
> is something else.  So let's stop pretending and let's just call it
> "vc-commit".

But when there's nothing to commit, I'd expect vc-next-action to
update from upstream.  So calling it "vc-commit" would be wrong, and
removing the update (a.k.a. "checkout") part from it would also be
wrong, IMO.

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

[Stefan Monnier]

> But when there's nothing to commit, I'd expect vc-next-action to
> update from upstream.

Yes, indeed, in some rare cases it can indeed notice that commit is not
an option and suggest something else.

> So calling it "vc-commit" would be wrong, and removing the update
> (a.k.a. "checkout") part from it would also be wrong, IMO.

That's why I said I was not 100% serious.  Still, AFAIK in typical usage
of modern VCS, vc-next-action ends up doing a commit about 99% of the
time, and its "dwim" behavior is largely useless.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  dgutov@yandex.ru,  stephen@xemacs.org,  dak@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 02 Oct 2015 08:54:00 -0400
> 
> AFAIK in typical usage of modern VCS, vc-next-action ends up doing a
> commit about 99% of the time, and its "dwim" behavior is largely
> useless.

FWIW, I always do a "git pull" before committing, to avoid unnecessary
merges.  So your percentage is wrong for me.

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

[Dmitry Gutov]

On 10/02/2015 04:42 PM, Eli Zaretskii wrote:

> FWIW, I always do a "git pull" before committing, to avoid unnecessary
> merges.  So your percentage is wrong for me.

Using `vc-next-action'? While local changes are present?

How does that happen?

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

[Eli Zaretskii]

> Cc: rms@gnu.org, stephen@xemacs.org, dak@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 2 Oct 2015 17:32:58 +0300
> 
> On 10/02/2015 04:42 PM, Eli Zaretskii wrote:
> 
> > FWIW, I always do a "git pull" before committing, to avoid unnecessary
> > merges.  So your percentage is wrong for me.
> 
> Using `vc-next-action'?

No.

> While local changes are present?

Yes.

> How does that happen?

I don't understand the question.  I just issue the pertinent Git
commands, that's all.

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

[Dmitry Gutov]

On 10/02/2015 05:40 PM, Eli Zaretskii wrote:

>> Using `vc-next-action'?
>
> No.

Then that doesn't refute that statement, does it?

"Still, AFAIK in typical usage of modern VCS, vc-next-action ends up 
doing a commit about 99% of the time".

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 2 Oct 2015 17:54:04 +0300
> 
> On 10/02/2015 05:40 PM, Eli Zaretskii wrote:
> 
> >> Using `vc-next-action'?
> >
> > No.
> 
> Then that doesn't refute that statement, does it?

No.

> "Still, AFAIK in typical usage of modern VCS, vc-next-action ends up 
> doing a commit about 99% of the time".

We are talking about what vc-next-action _should_ do.  I'm saying that
it would make sense for it to always check whether update is needed,
or maybe even actually do it.

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

[Stefan Monnier]

> We are talking about what vc-next-action _should_ do.  I'm saying that
> it would make sense for it to always check whether update is needed,
> or maybe even actually do it.

As soon as vc-commit is available and bound to a key like C-x v c, we
can consider making vc-next-action more dwimish and willing to try
new ideas.

But as it currently stands, we can't do what you suggest because it
would make it impossible to commit (with VC) without pulling first,
which many people will object to.


        Stefan


PS: And of course, in Git, "git pull" will often refuse to work if you have
uncommitted changes to files ("often" as in: whenever a file is modified
both locally and by the pulled changes), so "pull before commit" would
not be straightforward at least in Git.

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

[Dmitry Gutov]

On 10/02/2015 05:59 PM, Eli Zaretskii wrote:

> We are talking about what vc-next-action _should_ do.  I'm saying that
> it would make sense for it to always check whether update is needed,
> or maybe even actually do it.

In addition to problems Stefan mentioned (can't commit without pulling; 
a pull can fail), that would be a speed bump.

And "pull before committing" is non-idiomatic Git workflow, so we 
probably shouldn't use it by default either way.

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

[Eli Zaretskii]

> Cc: rms@gnu.org, "Stephen J. Turnbull" <stephen@xemacs.org>, eliz@gnu.org,
>  dak@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 30 Sep 2015 05:27:37 +0300
> 
> On 09/23/2015 08:33 PM, Stefan Monnier wrote:
> >>> Yes, M-x vc-commit RET should definitely ignore the "up to date" status.
> >> By vc-commit, do you mean vc-next-action, or a new command?
> >
> > Nowadays (as in "with modern VCS"), vc-next-action can't do much
> > beside commit, and `vc-next-action' is also the only command which
> > can do "commit".
> 
> It also performs that weird step: "If every file in the VC fileset is 
> not registered for version control, register the fileset (but don't 
> commit)", aborting if some of the files in the fileset are unregistered 
> and others are registered.
> 
> It would make sense to remove it (and commit all selected files), but it 
> would be nice to know what prompted its existence in the first place.

I guess it tries to follow the same workflow that existed initially
for file-based VCSes: if the file you act on is not registered, the
most (perhaps the only) reasonable thing to do is register it.

Why are you saying it's weird for modern VCSes?  I envision a
situation where I create several new files and want to add them to
version control.  What situation did you have in mind where what
vc-next-action currently does makes little or no sense?

> This could also be dropped (we have a separate command for it):
> 
> "For a centralized version control system, if any work file in the VC 
> fileset is out of date, offer to update the fileset."

Are you saying this makes no sense for CVS or SVN?  A dVCS is not
affected, so why drop this?

In general, IMO dropping such features has 2 disadvantages: it causes
bug reports when users who are used to using them upgrade and find
they lost them; and spawns endless discussions here that lead nowhere,
because there are 2 different crowds involved whose opinions cannot be
easily reconciled.  The only advantage is that it makes the code
simpler, but IMO this is an ephemeral advantage: the code is not that
complicated, the only thing that might be missing is some comments to
explain why some things, such as what described above, are done
(because not everyone is familiar with all the back-ends we support).

In all the years I'm involved with Emacs development, I think the last
round of changes in VC (I mean the one 9 months or so ago) was the
first time I saw features dropped not because they are unused or
incorrectly implemented, but because those who advocated dropping them
have no use for the back-ends those features support, and some simply
dislike those back-ends.  I don't think this is how we should make
such decisions.

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

[Dmitry Gutov]

On 09/30/2015 09:37 AM, Eli Zaretskii wrote:

> I guess it tries to follow the same workflow that existed initially
> for file-based VCSes: if the file you act on is not registered, the
> most (perhaps the only) reasonable thing to do is register it.

Registering it is not my end goal. Committing it is.

> Why are you saying it's weird for modern VCSes?  I envision a
> situation where I create several new files and want to add them to
> version control.  What situation did you have in mind where what
> vc-next-action currently does makes little or no sense?

It's just inefficient: I often have a set of new as well as modified 
files that implement a new feature. Before I can commit them, I have to 
hunt the unregistered files in vc-dir (or at least one of them, to press 
M then) and make them registered. If I already marked some registered 
files (because I forgot about the unregistered one), I have to unmark 
them and start from the beginning.

Unless some backends absolutely can't commit unregistered files, we can 
skip that step. And even then, registering them could be a part of a 
backend's checkin implementation.

>> "For a centralized version control system, if any work file in the VC
>> fileset is out of date, offer to update the fileset."
>
> Are you saying this makes no sense for CVS or SVN?  A dVCS is not
> affected, so why drop this?

In the vc-commit's command implementation, of course. It would make no 
sense there.

> In general, IMO dropping such features has 2 disadvantages: it causes
> bug reports when users who are used to using them upgrade and find
> they lost them; and spawns endless discussions here that lead nowhere,
> because there are 2 different crowds involved whose opinions cannot be
> easily reconciled.

If a maintainer could make a decision like that without others 
second-guessing them, we could stop discussions like the ones you 
mentioned with "just do XX now". Be it using a new VC command, or the 
command-line.

> The only advantage is that it makes the code
> simpler, but IMO this is an ephemeral advantage: the code is not that
> complicated,

It's complicated enough that it's not easy to implement the generic 
"amend" functionality on top of vc-next-action.

> In all the years I'm involved with Emacs development, I think the last
> round of changes in VC (I mean the one 9 months or so ago) was the
> first time I saw features dropped not because they are unused or
> incorrectly implemented, but because those who advocated dropping them
> have no use for the back-ends those features support, and some simply
> dislike those back-ends.

That's a misrepresentation of the arguments given in favor of that 
vc-checkin change.

At the end of the day, we should be able to drop features that don't 
make sense for VC. The user can access them via the command-line. As 
long as those aren't used too often, that's not a big loss.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 30 Sep 2015 14:27:56 +0300
> 
> On 09/30/2015 09:37 AM, Eli Zaretskii wrote:
> 
> > I guess it tries to follow the same workflow that existed initially
> > for file-based VCSes: if the file you act on is not registered, the
> > most (perhaps the only) reasonable thing to do is register it.
> 
> Registering it is not my end goal. Committing it is.

Of course.

> > Why are you saying it's weird for modern VCSes?  I envision a
> > situation where I create several new files and want to add them to
> > version control.  What situation did you have in mind where what
> > vc-next-action currently does makes little or no sense?
> 
> It's just inefficient: I often have a set of new as well as modified 
> files that implement a new feature. Before I can commit them, I have to 
> hunt the unregistered files in vc-dir (or at least one of them, to press 
> M then) and make them registered. If I already marked some registered 
> files (because I forgot about the unregistered one), I have to unmark 
> them and start from the beginning.

Well, with RCS as the back-end, "register" actually commits.  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.
I just hope this won't be a big surprise for people who are used to it
only adding files without committing them.

> Unless some backends absolutely can't commit unregistered files, we can 
> skip that step. And even then, registering them could be a part of a 
> backend's checkin implementation.

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.

> >> "For a centralized version control system, if any work file in the VC
> >> fileset is out of date, offer to update the fileset."
> >
> > Are you saying this makes no sense for CVS or SVN?  A dVCS is not
> > affected, so why drop this?
> 
> In the vc-commit's command implementation, of course. It would make no 
> sense there.

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.

> > In general, IMO dropping such features has 2 disadvantages: it causes
> > bug reports when users who are used to using them upgrade and find
> > they lost them; and spawns endless discussions here that lead nowhere,
> > because there are 2 different crowds involved whose opinions cannot be
> > easily reconciled.
> 
> If a maintainer could make a decision like that without others 
> second-guessing them, we could stop discussions like the ones you 
> mentioned with "just do XX now". Be it using a new VC command, or the 
> command-line.

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.

> > In all the years I'm involved with Emacs development, I think the last
> > round of changes in VC (I mean the one 9 months or so ago) was the
> > first time I saw features dropped not because they are unused or
> > incorrectly implemented, but because those who advocated dropping them
> > have no use for the back-ends those features support, and some simply
> > dislike those back-ends.
> 
> That's a misrepresentation of the arguments given in favor of that 
> vc-checkin change.

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

> At the end of the day, we should be able to drop features that don't 
> make sense for VC.

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.

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.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.

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

[Dmitry Gutov]

On 10/01/2015 10:18 AM, Eli Zaretskii wrote:

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

The term "makes sense" usually doesn't take into account backward 
compatibility.

If it did, your agreement with "we should be able to drop features that 
don't make sense" is a no-op, because any existing feature would, by 
definition, make sense. Right?

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 15:54:21 +0300
> 
> The term "makes sense" usually doesn't take into account backward 
> compatibility.
> 
> If it did, your agreement with "we should be able to drop features that 
> don't make sense" is a no-op, because any existing feature would, by 
> definition, make sense. Right?

No.  Existing features might make no sense if (a) they didn't make
sense when introduced (it happens!), or (b) if the reason for their
existence is no longer valid, like a program that is no longer
available, or operation that is impossible with today's platforms, or
so clearly unused that there's no doubt it could be still useful to
anyone.

Breaking backward compatibility is about the worst crime package
maintainers could commit, in my opinion.  (I know it's not shared by
many of the others.)  It makes veteran users of a package feel like
second-class citizens whose needs and workflows can be disregarded all
too easily.

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

[Dmitry Gutov]

On 10/01/2015 04:07 PM, Eli Zaretskii wrote:

> No.  Existing features might make no sense if (a) they didn't make
> sense when introduced (it happens!),

You mean features that were useless or broken from the start?

> or (b) if the reason for their
> existence is no longer valid, like a program that is no longer
> available, or operation that is impossible with today's platforms, or
> so clearly unused that there's no doubt it could be still useful to
> anyone.

...or became irreparably broken over time. That's a pretty high standard 
to consider a feature for removal.

When I said "doesn't make sense", I meant sense in the context of the VC 
framework. Which supposedly has some internal logic, ergonomics, etc.

> Breaking backward compatibility is about the worst crime package
> maintainers could commit, in my opinion.  (I know it's not shared by
> many of the others.)

This general opinion (and you're not alone holding it) is one of the 
most tedious parts of the Emacs ecosystem, IME. It's not that I *love* 
removing features, but being unable to do that at all makes the burden 
of a maintainer harder when making changes or adding new features.

> It makes veteran users of a package feel like
> second-class citizens whose needs and workflows can be disregarded all
> too easily.

Removing features is always a tradeoff. While no one wants to make old 
users sad, if their needs would still be achievable at the cost of 
workflow changes, we should be able to make that sacrifice.

At some point in the future (distant, in all likelihood, so this is just 
a rough example), I imagine that would mean sacrificing support for 
antique VC backends entirely, in favor of simpler VC implementation, or 
better support of the newer backends. There's nothing stopping the 
veterans from adopting modern VCSes, you know.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 20:36:19 +0300
> 
> On 10/01/2015 04:07 PM, Eli Zaretskii wrote:
> 
> > No.  Existing features might make no sense if (a) they didn't make
> > sense when introduced (it happens!),
> 
> You mean features that were useless or broken from the start?

Yes, something like that.

> > or (b) if the reason for their
> > existence is no longer valid, like a program that is no longer
> > available, or operation that is impossible with today's platforms, or
> > so clearly unused that there's no doubt it could be still useful to
> > anyone.
> 
> ...or became irreparably broken over time. That's a pretty high standard 
> to consider a feature for removal.

I indeed think that features should rarely be removed, only added.

> When I said "doesn't make sense", I meant sense in the context of the VC 
> framework. Which supposedly has some internal logic, ergonomics, etc.

Yes, but different VCSes have different internal logic, so something
might make sense with RCS, but not with Git, or vice versa.  That's
the crux of the problem we are discussing, I think, so the question is
whether a feature must make sense for every back-end for it to be
considered as sensible.

> > Breaking backward compatibility is about the worst crime package
> > maintainers could commit, in my opinion.  (I know it's not shared by
> > many of the others.)
> 
> This general opinion (and you're not alone holding it) is one of the 
> most tedious parts of the Emacs ecosystem, IME. It's not that I *love* 
> removing features, but being unable to do that at all makes the burden 
> of a maintainer harder when making changes or adding new features.

We do remove features that are obsolete or no longer needed.  E.g.,
see the 'lisp/obsolete' directory.  And yes, it is harder to make
changes while keeping backward compatibility.  But I don't think the
"solution" of breaking backward compatibility is the main or even
desirable one.  It should be the last resort, unless we are sure the
feature is of no use.

> > It makes veteran users of a package feel like
> > second-class citizens whose needs and workflows can be disregarded all
> > too easily.
> 
> Removing features is always a tradeoff. While no one wants to make old 
> users sad, if their needs would still be achievable at the cost of 
> workflow changes, we should be able to make that sacrifice.

For some features, a change of the workflow could be justified, for
others, those which are too popular and ubiquitous with their users,
it can't.  I disagree that this sacrifice is always possible, let
alone desirable.  Especially when the change in the workflow boils
down to "do it from outside Emacs".

> At some point in the future (distant, in all likelihood, so this is just 
> a rough example), I imagine that would mean sacrificing support for 
> antique VC backends entirely, in favor of simpler VC implementation, or 
> better support of the newer backends.

I think there's a better alternative: start a new front end, which
will only support a subset of back-ends.  Then the elders can
peacefully continue using the old front-end, which will more or less
stop being developed, only maintained whenever some of the
infrastructure changes absolutely require that.

> There's nothing stopping the veterans from adopting modern VCSes,
> you know.

Muscle memory is what stopping them.  It's a powerful thing.

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

[Dmitry Gutov]

On 10/01/2015 08:52 PM, Eli Zaretskii wrote:

> I indeed think that features should rarely be removed, only added.

Then you must be prepared that at certain point the cost of improving 
Emacs will be too much for anyone to do anything of significance to it.

> Yes, but different VCSes have different internal logic, so something
> might make sense with RCS, but not with Git, or vice versa.  That's
> the crux of the problem we are discussing, I think, so the question is
> whether a feature must make sense for every back-end for it to be
> considered as sensible.

It may be decided on a case-by-case basis, but the question is rather 
whether it *could* be decided at all. The exact criterion, "make sense 
for at least a half of all backends", or "make sense in at least one of 
the modern backends", is up for discussion.

> I disagree that this sacrifice is always possible, let
> alone desirable.  Especially when the change in the workflow boils
> down to "do it from outside Emacs".

I still think it's just fine for rare operations. Even those performed 
regularly, but at long-ish intervals.

> I think there's a better alternative: start a new front end, which
> will only support a subset of back-ends.  Then the elders can
> peacefully continue using the old front-end, which will more or less
> stop being developed, only maintained whenever some of the
> infrastructure changes absolutely require that.

It's an option indeed, though one that requires a larger investment of 
time (which we don't have a lot of to spare). And what if we make some 
unfortunate decision WRT to features when creating the second front-end, 
too? Wait a few years and create a third one?

It also assumes that the set of backend commands can be static without 
incurring any cost. Whereas the most recent overhaul by ESR featured 
some beneficial changes in it.

> Muscle memory is what stopping them.  It's a powerful thing.

It's easier to change than a big codebase full of features one is 
absolutely not allowed to break.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 22:29:30 +0300
> 
> On 10/01/2015 08:52 PM, Eli Zaretskii wrote:
> 
> > I indeed think that features should rarely be removed, only added.
> 
> Then you must be prepared that at certain point the cost of improving 
> Emacs will be too much for anyone to do anything of significance to it.

That's a very distant possibility.  In general, most features are only
very loosely coupled, so the complexity increases very slowly,
certainly sub-linearly.  I don't see why we should be afraid of this
happening any time soon.

> > Yes, but different VCSes have different internal logic, so something
> > might make sense with RCS, but not with Git, or vice versa.  That's
> > the crux of the problem we are discussing, I think, so the question is
> > whether a feature must make sense for every back-end for it to be
> > considered as sensible.
> 
> It may be decided on a case-by-case basis, but the question is rather 
> whether it *could* be decided at all. The exact criterion, "make sense 
> for at least a half of all backends", or "make sense in at least one of 
> the modern backends", is up for discussion.

I think the popularity of a back-end should also be taken into
account.  SCCS, for example, is probably not very used.  We removed
vc-arch some time ago, for the same reasons.

> > I think there's a better alternative: start a new front end, which
> > will only support a subset of back-ends.  Then the elders can
> > peacefully continue using the old front-end, which will more or less
> > stop being developed, only maintained whenever some of the
> > infrastructure changes absolutely require that.
> 
> It's an option indeed, though one that requires a larger investment of 
> time

If it requires more time, then the situation with the existing
front-end is not too bad.  When it's really bad, forking a new
front-end should be much easier.

> And what if we make some unfortunate decision WRT to features when
> creating the second front-end, too? Wait a few years and create a
> third one?

We should try not to make unfortunate decisions.

> It also assumes that the set of backend commands can be static without 
> incurring any cost.

For old back-ends that no longer see significant development,
definitely.

> > Muscle memory is what stopping them.  It's a powerful thing.
> 
> It's easier to change than a big codebase full of features one is 
> absolutely not allowed to break.

Yes, because someone else needs to change ;-)

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

[Dmitry Gutov]

On 10/01/2015 10:54 PM, Eli Zaretskii wrote:

> That's a very distant possibility.  In general, most features are only
> very loosely coupled, so the complexity increases very slowly,
> certainly sub-linearly.  I don't see why we should be afraid of this
> happening any time soon.

We can disregard orthogonal features, but with related features, 
complexity increases combinatorially.

> If it requires more time, then the situation with the existing
> front-end is not too bad.  When it's really bad, forking a new
> front-end should be much easier.

The amount of work required for that option is independent of the 
situation with the existing front-end. If anything, it would be the 
reverse: the worse the current solution is, the more work needed to 
re-implement it.

> We should try not to make unfortunate decisions.

We made them before, and we'll do them again.

>> It also assumes that the set of backend commands can be static without
>> incurring any cost.
>
> For old back-ends that no longer see significant development,
> definitely.

VC doesn't consist solely of backends.

> Yes, because someone else needs to change ;-)

Humans can forget the previous workflow after switching to the new one, 
and the complexity of the new "muscle memory network" can remain on the 
same order as the previous one.

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

[Drew Adams]

> > Breaking backward compatibility is about the worst crime package
> > maintainers could commit, in my opinion.  (I know it's not shared by
> > many of the others.)
> 
> This general opinion (and you're not alone holding it) is one of the
> most tedious parts of the Emacs ecosystem, IME. It's not that I *love*
> removing features, but being unable to do that at all makes the burden
> of a maintainer harder when making changes or adding new features.

Emacs is not just for its maintainers.  It is above all for its users.

And plenty of users, for plenty of reasons, do not use the latest &
greatest version of Emacs.  And yes, Emacs is exceptional in its aim
to be especially easy for users to extend.  Emacs is _designed_ for
user extension and customization (as is Lisp, BTW).

> Removing features is always a tradeoff. While no one wants to make old
> users sad, if their needs would still be achievable at the cost of
> workflow changes, we should be able to make that sacrifice.

Whose workflow?  Are you saying that you are willing to sacrifice
a user's workflow & habits, so they can take advantage of the latest
shiny new features you have to offer?  How gracious of you!

> At some point in the future (distant, in all likelihood, so this is just
> a rough example), I imagine that would mean sacrificing support for
> antique VC backends entirely, in favor of simpler VC implementation, or
> better support of the newer backends. There's nothing stopping the
> veterans from adopting modern VCSes, you know.

There can be plenty of things stopping a given user from adopting
your favorite modern whatever, including a VCS.

Many users use tools, including Emacs that are installed
organization-wide (e.g., company-wide).

What percentage of Emacs users do you think build Emacs themselves
for their use at work?  (No, I don't have a figure in mind, but
I'm pretty sure that the average core Emacs maintainer/developer
is not a typical user.)

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

[Dmitry Gutov]

On 10/02/2015 02:55 AM, Drew Adams wrote:

> Emacs is not just for its maintainers.  It is above all for its users.

You don't say.

> And plenty of users, for plenty of reasons, do not use the latest &
> greatest version of Emacs.

They can continue using those, too.

> Whose workflow?  Are you saying that you are willing to sacrifice
> a user's workflow & habits, so they can take advantage of the latest
> shiny new features you have to offer?  How gracious of you!

Sometimes, yes. As long as we don't do that too often, the cost/benefit 
ratio should be decent.

Thank you for the compliment.

> There can be plenty of things stopping a given user from adopting
> your favorite modern whatever, including a VCS.

Yes. Some users will end up unhappy anyway (cue xkcd#1172), we just have 
to try to maximize the benefits.

And keep an eye out for the future. Focusing exclusively on the existing 
user base means you don't optimize for the new users, and when the older 
generations pass away, Emacs is more likely to die with them.

> Many users use tools, including Emacs that are installed
> organization-wide (e.g., company-wide).

If a company mandates the version of Emacs, it could as well coordinate 
it with the VCS the company uses.

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

[Drew Adams]

> Focusing exclusively on the existing user base

Strawman argument.  No one has suggested doing such a thing.

> means you don't optimize for the new users, and when the older
> generations pass away, Emacs is more likely to die with them.

Existing vs new users is not about old vs young users.
Existing, sometimes organizational, installations of Emacs
are not about old vs young users.  Or even about experienced
vs newbie users.  Plenty of new Emacs users use old versions
that are installed in their organization, and in situations
where they cannot install a newer version.

Old vs young, indeed!  You are playing to the gallery with
such arguments.

Believe it or not, existing, sometimes quite old versions
of Emacs are actually used by many people who do real work.
Including young developers and Emacs newbies.

It's not about "focusing exclusively" on such users.  But
it is about keeping them in mind.  They are, or should be,
one important consideration for Emacs development.

> > Many users use tools, including Emacs that are installed
> > organization-wide (e.g., company-wide).
> 
> If a company mandates the version of Emacs, it could as
> well coordinate it with the VCS the company uses.

So it seems it is not only individual Emacs users whose
"workflows" need to change to fit your development - it
is also company tools and workflows.  Sheesh.

And IIUC, that's already coordinated by Emacs, with its
various `vc-*' functions.  But my reply had nothing to do,
particularly, with the current specific discussion about
`vc-*' commands.

I responded to your _general_ argument expressing your
apparent willingness to sacrifice user workflows, backward
compatibility, and our existing user base - your general
criticism of Eli's prioritizing not breaking backward
compatibility.

You think of such consideration as "one of the most
tedious parts of the Emacs ecosystem."  I don't.  Eli is
right to give importance to backward compatibility, and
it's a shame that this view is so little shared here.
That has not always been the case.

Yes, I suppose it is, to some degree, about your personal
"tedium", as you and your contributions are a valued part
of "the Emacs ecosystem" - we don't want to sacrifice them.
(I am not being facetious at all.)

But that goes only so far.  Your tedium is only one
important consideration, IMHO.  Users count too.  Backward
compatibility is all about users.  It's not about you.
Unfortunately, yes, taking backward compatibility into
account can mean more work for maintainers.  But Emacs
maintainers should have Emacs users foremost in mind.

Not all users care about backward compatibility.  But some
do.  All maintainers should therefore care about backward
compatibility (IMHO).

You like to point out the danger of Emacs stagnating or
slipping into oblivion.  Well IMHO, you need look no
further than this, for a threat to Emacs remaining vibrant
and relevant 20 or 40 years from now: maintainers who think
too much about their own tedium and not enough about Emacs
users.

If you ask me how Emacs has managed to remain healthy and
relevant all these many years, my answer is the dedication
of its maintainers to its users, and in particular the
over-the-top, "abnormal" concern of RMS and Eli (& others)
for such silly, old-fashioned things as documentation and
backward compatibility.  May we get more like them.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Breaking backward compatibility is about the worst crime package
  > maintainers could commit, in my opinion.

I mostly agree.  If we want to drop a feature, we should mark it
obsolete in version N and delete it in version N+1 or N+2.  Thus, if
we mark it obsolete in version 25, we could delete it in version 26.
We must never feel any hurry to do this.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Dmitry Gutov]

On 10/02/2015 05:27 AM, Richard Stallman wrote:

> I mostly agree.  If we want to drop a feature, we should mark it
> obsolete in version N and delete it in version N+1 or N+2.  Thus, if
> we mark it obsolete in version 25, we could delete it in version 26.
> We must never feel any hurry to do this.

I'd pretty much agree if we were talking about functions that might be 
used in third-party code. But you can't mark a key binding as obsolete.

And if we provide a replacement for vc-next-action in the form of 
vc-commit that simplifies usage and cuts on unused features such a 
"steal lock", is there a reason not to replace its binding in the same 
release where we introduce the new command?

We might keep vc-next-action defined for the time being, if only to 
allow users to revert the binding, in case some people actually use the 
"steal lock" functionality.

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

[Dmitry Gutov]

On 10/02/2015 05:27 AM, Richard Stallman wrote:

> I mostly agree.  If we want to drop a feature, we should mark it
> obsolete in version N and delete it in version N+1 or N+2.

In any case, "obsolete in one version, drop in the next one" is rather 
different from "never remove features".

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

[Uwe Brauer]

   > If you feel it's really important that user be able to delete a
   > revision from within Emacs, why not provide a vc-rcs-delete-commits
   > command in vc-rcs.el? That would be a lot simpler to implement and
   > wouldn't force us to come up with some weird pseudo-generic
   > functionality that might end up not even supporting 100% of RCS's
   > use cases.

I presume you mean something more sophisticated than the one I posted a couple
of days ago? since my wrapper depends on the shell-command and I  am not
sure whether it would work under MS windows.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

There is already a vc-revert command.  I think it changes the working files
to match what is in the repository.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Uwe Brauer]

>> "Richard" == Richard Stallman <rms@gnu.org> writes:

   > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
   > [[[ whether defending the US Constitution against all enemies,     ]]]
   > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > There is already a vc-revert command.  I think it changes the working files
   > to match what is in the repository.

I tested it. Once you checkin, you cannot «remove/revert» to the version
before the checkin, at least not for the RCS backend.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >    > There is already a vc-revert command.  I think it changes the working files
  >    > to match what is in the repository.

  > I tested it. Once you checkin, you cannot «remove/revert» to the version
  > before the checkin, at least not for the RCS backend.

That's right.  That's what vc-revert is supposed to do.

The command to delete a version from the repository used to be
vc-cancel.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > In CVS, removing a commit is easy and nonproblematic.  So this command
  > > could support CVS.  If it supports only one back end, that's better
  > > than none.

  > Could you point out that exact "easy and nonproblematic" way? Is it the 
  > admin-privilege command? Or adding a new commit that would revert 
  > changes in the previous one?

I don't know the details because I always did it via C-x v.  I think
the command was C-x v c.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Uwe Brauer]

>> "Richard" == Richard Stallman <rms@gnu.org> writes:

   > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
   > [[[ whether defending the US Constitution against all enemies,     ]]]
   > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   >> > In CVS, removing a commit is easy and nonproblematic.  So this command
   >> > could support CVS.  If it supports only one back end, that's better
   >> > than none.

   >> Could you point out that exact "easy and nonproblematic" way? Is it the 
   >> admin-privilege command? Or adding a new commit that would revert 
   >> changes in the previous one?

   > I don't know the details because I always did it via C-x v.  I think
   > the command was C-x v c.

Yes it was 

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, dak@gnu.org, dgutov@yandex.ru,
> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Tue, 22 Sep 2015 18:02:11 -0400
> 
> In CVS, removing a commit is easy and nonproblematic.  So this command
> could support CVS.  If it supports only one back end, that's better
> than none.

RCS can support it as well, it has the same -oRANGE option as
"cvs admin" does.  (Not surprisingly, since CVS repository is made of
RCS version files.)

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

[Stefan Monnier]

[ Sending in private, it's only for information.  ]

> LilyPond works with a "staging" branch and a "master" branch.  "master"
> only moves forward: once a commit is in there, it stays.  If its effects
> are to be annulled, it is reverted.  Nobody pushes to master though.
> Any changes are instead pushed to staging.  An automated task picks up

Sounds like an attractive organization.

One question, tho: how do you deal with (aka "synchronize") concurrent
"push" to the staging branch, if you allow the staging branch to be
"forced" (either via non-FF, or via remove+push)?


        Stefan

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ Sending in private, it's only for information.  ]

Well, didn't work apparently.

>> LilyPond works with a "staging" branch and a "master" branch.  "master"
>> only moves forward: once a commit is in there, it stays.  If its effects
>> are to be annulled, it is reverted.  Nobody pushes to master though.
>> Any changes are instead pushed to staging.  An automated task picks up
>
> Sounds like an attractive organization.
>
> One question, tho: how do you deal with (aka "synchronize") concurrent
> "push" to the staging branch, if you allow the staging branch to be
> "forced" (either via non-FF, or via remove+push)?

Forcing becomes necessary only in extraordinary circumstances.  The
person receiving the failure notices from the automated processes will
likely ask around and then fix the stuff.

In the situation where a committer discovers a blunder himself and fixes
it, there is a non-zero chance that he'll overwrite changes others
pushed after his faulty commit.

In practice, it's mostly myself doing the fixing after either I or
somebody else messed up.

Most are encouraged to
a) rebase on master
b) push to staging (unforced)
c) when non-ff failure, wait an hour or two, fetch and repeat

That's easiest and means you never have to back out changes but it means
arbitrary waiting times.  If you know what you are doing, you can also

a) git rebase origin feature_branch
b) git rebase origin/staging HEAD~0 (detaches HEAD from feature_branch)
c) git push origin HEAD:staging
d) git checkout feature_branch (returns to rebase on master)
e) push fail?  wait an hour, git fetch, restart from top

That way the rebase on staging in step b) does not permanently leave
commits in feature_branch.  Usually it's easiest if only one set of
changes at a time is placed in staging.

The basic premise here is that when something gets messed up, the
automated procedures reliably stop doing anything until somebody with a
reasonable amount of expertise has fixed the situation manually.  In the
meantime, master stays in useful state and work based on it can
continue.  The complication is rarely needed, but every month or two it
saves people from fingerpointing and tension because master locked up.
As an additional boon, the expert fixing the situation feels smug and in
control and is less likely to engage in heated exchanges.

-- 
David Kastrup

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

[Stefan Monnier]

> [ Sending in private, it's only for information.  ]

And I mean it.  So if you're reading it and your name is not "David
Kastrup", you should feel like a voyeur!



        Stefan

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

[Dmitry Gutov]

On 09/21/2015 09:50 AM, Eli Zaretskii wrote:

> If the commit was already pushed, you will need "git revert" instead,
> I think.

What does RCS do in this case?

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 17:02:19 +0300
> 
> On 09/21/2015 09:50 AM, Eli Zaretskii wrote:
> 
> > If the commit was already pushed, you will need "git revert" instead,
> > I think.
> 
> What does RCS do in this case?

There's no "push" in RCS.

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

[Dmitry Gutov]

On 09/21/2015 07:07 PM, Eli Zaretskii wrote:

>>> If the commit was already pushed, you will need "git revert" instead,
>>> I think.
>>
>> What does RCS do in this case?
>
> There's no "push" in RCS.

Then I think the correspondence of RCS commands will be Git commands 
that act similarly on the local repository.

Then 'git reset --hard HEAD^' is a better match, because, like someone 
explained, the point of 'rcs rollback' is to remove the revision in 
question from history.

And if 'git reset' is unsafe, well, 'rcs rollback' doesn't sound 
particularly safe either.

Either way, we need a smart way to detect dangerous operations (e.g. see 
if affected commits are already published). The "amend" Git capability, 
which we already support, is unsafe too.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 19:58:34 +0300
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On 09/21/2015 07:07 PM, Eli Zaretskii wrote:
> 
> >>> If the commit was already pushed, you will need "git revert" instead,
> >>> I think.
> >>
> >> What does RCS do in this case?
> >
> > There's no "push" in RCS.
> 
> Then I think the correspondence of RCS commands will be Git commands 
> that act similarly on the local repository.

But what about CVS?  Its "rollback" command does remove the commit
upstream.

> Then 'git reset --hard HEAD^' is a better match, because, like someone 
> explained, the point of 'rcs rollback' is to remove the revision in 
> question from history.

Going from RCS to Git needs some generalization, so if Git's rollback
will affect the remote, when it should, it's OK, I think.

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

[Dmitry Gutov]

On 09/21/2015 08:06 PM, Eli Zaretskii wrote:

> But what about CVS?  Its "rollback" command does remove the commit
> upstream.

CVS has a "rollback" command? But if it does, sure, that's exactly what 
I mean.

> Going from RCS to Git needs some generalization, so if Git's rollback
> will affect the remote, when it should, it's OK, I think.

It won't. That would be doubly dangerous. 'git revert', by itself, 
doesn't affect the remote either.

Like I said, for CVS/RCS/SVN commands (which unavoidably affect the 
remote, because there's no "local" repository), the correspondent 
commands in Git/Hg/Bzr will only act on the local repository.

We have `vc-push' for propagating those changes upstream.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 20:24:39 +0300
> 
> On 09/21/2015 08:06 PM, Eli Zaretskii wrote:
> 
> > But what about CVS?  Its "rollback" command does remove the commit
> > upstream.
> 
> CVS has a "rollback" command?

Yes, it does.  From the description of "cvs admin":

  admin options
  -------------

  [...]

  `-oRANGE'
       Deletes ("outdates") the revisions given by RANGE.

(It then goes on to describe the syntax of RANGE, basically
REV1::REV2.)

> But if it does, sure, that's exactly what I mean.
> 
> > Going from RCS to Git needs some generalization, so if Git's rollback
> > will affect the remote, when it should, it's OK, I think.
> 
> It won't. That would be doubly dangerous.

So is "cvs -o".  The CVS manual says that much.  Why should Git be
different?  A careful user won't invoke this command unless they know
what they are doing, right?

> 'git revert', by itself, doesn't affect the remote either.

Indeed, so what is the reason not to use it as "rollback"?

> Like I said, for CVS/RCS/SVN commands (which unavoidably affect the 
> remote, because there's no "local" repository), the correspondent 
> commands in Git/Hg/Bzr will only act on the local repository.
> 
> We have `vc-push' for propagating those changes upstream.

I agree.  But the original issue was whether a "rollback" should
invoke "git reset --hard" or "git revert", or sometimes one or the
other.  The issue never was about adding a "push" to that.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Mon, 21 Sep 2015 20:24:39 +0300
>> 
>> On 09/21/2015 08:06 PM, Eli Zaretskii wrote:
>> 
>> > But what about CVS?  Its "rollback" command does remove the commit
>> > upstream.
>> 
>> CVS has a "rollback" command?
>
> Yes, it does.  From the description of "cvs admin":
>
>   admin options
>   -------------
>
>   [...]
>
>   `-oRANGE'
>        Deletes ("outdates") the revisions given by RANGE.

Yeah, but that is a _repository_ administration option, meaning that
it's not sufficient to have client access.  Also it causes
inconsistencies with the clients' notion of what is in the repo and with
the historic record.  It's in the same class as "renaming files" in CVS,
namely the "when it breaks (and it will), you get to keep the pieces"
category.  Those are operations that can not be rolled back in any
manner (short of restoring from backup).  They just don't belong on key
bindings.

> So is "cvs -o".  The CVS manual says that much.  Why should Git be
> different?  A careful user won't invoke this command unless they know
> what they are doing, right?

I rather doubt that VC should invoke any cvs admin command.  I think VC
should restrict itself to client operations.  There is just too much
potential for damage to map this to standard VC commands (if Emacs wants
to provide specific CVS support outside of the normal VC commands,
that's a different topic).

-- 
David Kastrup

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

[Dmitry Gutov]

On 09/21/2015 10:17 PM, Eli Zaretskii wrote:

> Yes, it does.  From the description of "cvs admin":
 > ...
>    `-oRANGE'
>         Deletes ("outdates") the revisions given by RANGE.
>
> (It then goes on to describe the syntax of RANGE, basically
> REV1::REV2.)

Can it remove revisions from the tip, too? The description looks like it 
mostly applies to removing intermediate revisions in the middle of the 
history.

>> 'git revert', by itself, doesn't affect the remote either.
>
> Indeed, so what is the reason not to use it as "rollback"?

Like it's been said, 'rcs rollback' removes a revision from history 
(right?). 'git revert' doesn't.

That's an inconsistency that can be surprising for a user.

I use 'git reset' from time to time on the local history (and 'git 
revert' - considerably less often), so supporting the former would be 
also more useful for me personally.

> I agree.  But the original issue was whether a "rollback" should
> invoke "git reset --hard" or "git revert", or sometimes one or the
> other.  The issue never was about adding a "push" to that.

You said: "if Git's rollback will affect the remote, when it should, 
it's OK, I think". That implies a 'git push' in my mind.

Otherwise, 'git reset' and 'git revert' are roughly equivalent in this 
regard. It's just that 'git push' will fail upon being called after the 
former, in certain circumstances.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 22:33:42 +0300
> 
> On 09/21/2015 10:17 PM, Eli Zaretskii wrote:
> 
> > Yes, it does.  From the description of "cvs admin":
>  > ...
> >    `-oRANGE'
> >         Deletes ("outdates") the revisions given by RANGE.
> >
> > (It then goes on to describe the syntax of RANGE, basically
> > REV1::REV2.)
> 
> Can it remove revisions from the tip, too?

Yes.

> >> 'git revert', by itself, doesn't affect the remote either.
> >
> > Indeed, so what is the reason not to use it as "rollback"?
> 
> Like it's been said, 'rcs rollback' removes a revision from history 
> (right?). 'git revert' doesn't.

Because it's impossible.  But it does the closest thing possible.

> That's an inconsistency that can be surprising for a user.

I don't see this as an argument not to have the capability.

> Otherwise, 'git reset' and 'git revert' are roughly equivalent in this 
> regard. It's just that 'git push' will fail upon being called after the 
> former, in certain circumstances.

The idea of the proposal, namely, call 'revert' when 'reset' followed
by 'push' would fail, was to avoid the failure.

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

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Like it's been said, 'rcs rollback' removes a revision from history 
 > > (right?). 'git revert' doesn't.
 > 
 > Because it's impossible.  But it does the closest thing possible.

Of course it's possible to remove commits in git, including in a
publicly-accessible repository.  It is often unwise, but it's
possible, and sometimes a very good idea (as in Lilypond's "staging"
branch).

 > The idea of the proposal, namely, call 'revert' when 'reset' followed
 > by 'push' would fail, was to avoid the failure.

Users prefer a "true" rollback for several reasons.  One of the most
important is that the rolled-back commit causes a bisect "bad" result
(build or test failure, depending on the bisection criterion).  If
maintaining a "bisect-clean" branch is what you want, "revert" is the
wrong thing.

The probability the DWIM results in "Do What I Didn't Mean" here is
way too high.  If you want to do "revert" but call it "rollback", go
right ahead.  But don't do "reset" sometimes and "revert" in others.

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>     monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Tue, 22 Sep 2015 09:39:27 +0900
> 
>  > The idea of the proposal, namely, call 'revert' when 'reset' followed
>  > by 'push' would fail, was to avoid the failure.
> 
> Users prefer a "true" rollback for several reasons.

I prefer it, too.  But when the offending commit was already pushed,
'reset' is the only sane way.

> The probability the DWIM results in "Do What I Didn't Mean" here is
> way too high.  If you want to do "revert" but call it "rollback", go
> right ahead.  But don't do "reset" sometimes and "revert" in others.

I don't see why, but again, my steam for this argument is all but
used.

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

[Dmitry Gutov]

On 09/21/2015 10:53 PM, Eli Zaretskii wrote:

>> Otherwise, 'git reset' and 'git revert' are roughly equivalent in this
>> regard. It's just that 'git push' will fail upon being called after the
>> former, in certain circumstances.
>
> The idea of the proposal, namely, call 'revert' when 'reset' followed
> by 'push' would fail, was to avoid the failure.

It could work as a fallback, yes, after we have the "unsafe" predicate 
implemented. The user would need to be warned in some very obvious way, 
though.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 22 Sep 2015 16:08:05 +0300
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > The idea of the proposal, namely, call 'revert' when 'reset' followed
> > by 'push' would fail, was to avoid the failure.
> 
> It could work as a fallback, yes, after we have the "unsafe" predicate 
> implemented. The user would need to be warned in some very obvious way, 
> though.

I agree.  I think "rollback" should always trigger a warning, with any
VCS.

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

[Dmitry Gutov]

On 09/22/2015 04:45 PM, Eli Zaretskii wrote:

> I agree.  I think "rollback" should always trigger a warning, with any
> VCS.

Not sure what you mean. `vc-rollback' would be a command invoked 
explicitly by the user.

Maybe it would show a warning too, but the fact that 'git revert' is 
going to be used instead of 'git reset', deserves a separate warning.

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.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 22 Sep 2015 21:59:16 +0300
> 
> On 09/22/2015 04:45 PM, Eli Zaretskii wrote:
> 
> > I agree.  I think "rollback" should always trigger a warning, with any
> > VCS.
> 
> Not sure what you mean. `vc-rollback' would be a command invoked 
> explicitly by the user.
> 
> Maybe it would show a warning too

Yes, I think it should.

> but the fact that 'git revert' is going to be used instead of 'git
> reset', deserves a separate warning.

The warning could be worded differently in that case.

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

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

[Dmitry Gutov]

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?

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

Thinking about the issue more, 'git reset' is not that dangerous. 
*Especially* if the changes have been pushed to the remote. So even if 
you 'git reset HEAD^', but the commit has been pushed already, you can 
undo the operation simply by doing 'git pull', among other ways.

But 'git reset' without '--hard' sets you up to easily create 
conflicting commits, so it does invite confusion.

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. If those names seem too 
similar to someone, I welcome better suggestions.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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
published?

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

[Dmitry Gutov]

On 09/23/2015 09:58 AM, Eli Zaretskii wrote:

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

I don't like that very much (sounds complex). Better to have two 
commands, and allow a backend to signal error in one of them.

> 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
> published?

If the backend doesn't know when to signal an error, it won't. The RCS 
and CVS backend obviously won't do that.

A slight modification on that plan would be a new `revision-public' 
command which returns t if we're not supposed to modify or rollback that 
revision. Then the error would be raised not by vc-git, but by generic code.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > but the fact that 'git revert' is going to be used instead of 'git
  > > reset', deserves a separate warning.

  > The warning could be worded differently in that case.

Maybe the basic case warning could ask for y-or-n, and when there is
something fishy about the way rollback will be done, it will ask for
yes-or-no.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 20:24:39 +0300
> 
> On 09/21/2015 08:06 PM, Eli Zaretskii wrote:
> 
> > But what about CVS?  Its "rollback" command does remove the commit
> > upstream.
> 
> CVS has a "rollback" command?

Yes, it does.  From the description of "cvs admin":

  admin options
  -------------

  [...]

  `-oRANGE'
       Deletes ("outdates") the revisions given by RANGE.

(It then goes on to describe the syntax of RANGE, basically
REV1::REV2.)

> But if it does, sure, that's exactly what I mean.
> 
> > Going from RCS to Git needs some generalization, so if Git's rollback
> > will affect the remote, when it should, it's OK, I think.
> 
> It won't. That would be doubly dangerous.

So is "cvs -o".  The CVS manual says that much.  Why should Git be
different?  A careful user won't invoke this command unless they know
what they are doing, right?

> 'git revert', by itself, doesn't affect the remote either.

Indeed, so what is the reason not to use it as "rollback"?

> Like I said, for CVS/RCS/SVN commands (which unavoidably affect the 
> remote, because there's no "local" repository), the correspondent 
> commands in Git/Hg/Bzr will only act on the local repository.
> 
> We have `vc-push' for propagating those changes upstream.

I agree.  But the original issue was whether a "rollback" should
invoke "git reset --hard", "git revert", or sometimes one and
sometimes the other.  The issue never was about adding a "push" to
that.

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

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Yes, it does.  From the description of "cvs admin":

But IIRC cvs admin requires shell access to the repository host: you
can't use it from a client machine.

 > So is "cvs -o".  The CVS manual says that much.  Why should Git be
 > different?  A careful user won't invoke this command unless they know
 > what they are doing, right?

A user should not be able to invoke this command at all.

 > > 'git revert', by itself, doesn't affect the remote either.
 > 
 > Indeed, so what is the reason not to use it as "rollback"?

In git, "revert" has the wrong semantics; it adds a commit rather than
removing one.  This would surely confuse anybody who knows a little
bit about databases.

 > I agree.  But the original issue was whether a "rollback" should
 > invoke "git reset --hard", "git revert", or sometimes one and
 > sometimes the other.  The issue never was about adding a "push" to
 > that.

The problem is that users don't push commits.  They push branches.
That resets the ref on the remote end, which will confuse all derived
branches that include the rolled-back commit, even if you don't get
the usual rebase lossage.

My personal take is that `vc-rollback' should do "git reset" (no
--hard!), "hg strip", etc as available on the theory that "rollback"
refers to an in-progress database operation, not the users' edits in
the workspace.  If the user really wants that effect, they can fullow
up with a force-checkout.

If you do implement it as "git reset --hard", it had better have a
warning prompt like, "If you do this, you will lose all work involved
in this commit, in the repo and in your workspace.  Proceed?"

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>     monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Tue, 22 Sep 2015 09:26:12 +0900
> 
> Eli Zaretskii writes:
> 
>  > Yes, it does.  From the description of "cvs admin":
> 
> But IIRC cvs admin requires shell access to the repository host: you
> can't use it from a client machine.

I think you are wrong (I think I used it once or twice on a client),
but my CVS is rusty.

>  > > 'git revert', by itself, doesn't affect the remote either.
>  > 
>  > Indeed, so what is the reason not to use it as "rollback"?
> 
> In git, "revert" has the wrong semantics; it adds a commit rather than
> removing one.  This would surely confuse anybody who knows a little
> bit about databases.

But that's the only sane thing to do when a commit was pushed.

>  > I agree.  But the original issue was whether a "rollback" should
>  > invoke "git reset --hard", "git revert", or sometimes one and
>  > sometimes the other.  The issue never was about adding a "push" to
>  > that.
> 
> The problem is that users don't push commits.  They push branches.
> That resets the ref on the remote end, which will confuse all derived
> branches that include the rolled-back commit, even if you don't get
> the usual rebase lossage.

Since 'revert' just adds another commit, I don't see why they will be
confused.

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

[Stefan Monnier]

>> > Yes, it does.  From the description of "cvs admin":
>> But IIRC cvs admin requires shell access to the repository host: you
>> can't use it from a client machine.
> I think you are wrong (I think I used it once or twice on a client),
> but my CVS is rusty.

IIRC indeed it works remotely as well.  But in both cases (remote/local)
it only works if you're in the "cvsadmin" group, or something like that
(at least I remember it became inaccessible to me for cvs.sv.gnu.org at
some point).


        Stefan

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

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

> In git, "revert" has the wrong semantics; it adds a commit rather than
> removing one.  This would surely confuse anybody who knows a little
> bit about databases.

I would have thought that was similar to what a database log contains,
and therefore familiar to a database person?

Also similar to "event sourcing" (which is the currently hot concept in
lock-free storage in microservices, if the JavaZone talks are to be
trusted...?).

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

[Steinar Bang]

>>>>> Uwe Brauer <oub@mat.ucm.es>:

> I confess I have no idea how this concept makes sense in git and
> friends but I know that it makes a lot of sense in RCS.

(FWIW it makes perfect sense in git, unless, and until you have pushed
to a remote)