From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: In support of Jonas Bernoulli's Magit Date: Sun, 09 Jul 2017 17:19:09 +0300 Message-ID: <83mv8dk80y.fsf@gnu.org> References: <8737aac0rb.fsf@wanadoo.es> <7s37aapc4g.fsf@fencepost.gnu.org> <87bmouvu5z.fsf@jane> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499610020 18104 195.159.176.226 (9 Jul 2017 14:20:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Jul 2017 14:20:20 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca, raman@google.com To: Marcin Borkowski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 09 16:20:16 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dUD4H-0004Cj-1y for ged-emacs-devel@m.gmane.org; Sun, 09 Jul 2017 16:20:13 +0200 Original-Received: from localhost ([::1]:36339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUD4K-0001dS-N9 for ged-emacs-devel@m.gmane.org; Sun, 09 Jul 2017 10:20:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUD3c-0001cw-Ea for emacs-devel@gnu.org; Sun, 09 Jul 2017 10:19:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUD3b-0007Cm-5v for emacs-devel@gnu.org; Sun, 09 Jul 2017 10:19:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUD3U-000761-DL; Sun, 09 Jul 2017 10:19:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3110 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dUD3M-0002U2-WF; Sun, 09 Jul 2017 10:19:17 -0400 In-reply-to: <87bmouvu5z.fsf@jane> (message from Marcin Borkowski on Sun, 09 Jul 2017 11:25:28 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216366 Archived-At: > From: Marcin Borkowski > Date: Sun, 09 Jul 2017 11:25:28 +0200 > Cc: emacs-devel@gnu.org, Richard Stallman , > Stefan Monnier > > The main annoyance is that if I edit _more than one file_, and press C-x > v v, instead of committing my all changes (or at least asking me about > it), it only commits the changes in the currently edited file. Several > times I made an incomplete commit because of that. I tried to find an > option to override this, but to no avail. You can do what you want with VC by first marking the files you want to commit in vc-dir buffer. > I guess that Emacs' VC with distributed VCSs is fundamentally broken, > since it was really designed with RCS and its likes in mind You seem to talk only about "C-x v v". That command doesn't assume RCS-type VCS, it assumes that there's some more-or-less constant sequence of actions in your workflow, and attempts to support that sequence by doing "the next thing". I think this concept can be naturally generalized to modern VCSes, except that the number of different workflows is larger, definitely more than one. At the time, I proposed to move in that direction, but people disagreed, so nothing happened. I still think it's a good idea, so maybe someone will want to work on it. But VC includes more than "C-x v v" alone. There are commands like "C-x v D", "C-x v ~" (just recently mentioned as very important and useful -- with Git, no less!), "C-x v g" with its sub-commands, "C-x v l", "C-x v L", "C-x v I"/"C-x v O", "V-x v u", and others. I see no reasons to ignore these useful commands when talking about VC. > Sorry if that sounds harsh, but I consider VC's utility (with DVCSs) to > be zero _at best_. I think this is at least exaggerated. I certainly don't see how this could follow from what VC provides.