From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: On the adoption of transient.el Date: Thu, 05 Aug 2021 19:17:44 +0300 Message-ID: <83eeb7kgrb.fsf@gnu.org> References: <877di4on3d.fsf@posteo.net> <87im1oy6mw.fsf@posteo.net> <87y29hihea.fsf@posteo.net> <87sfzonu6k.fsf@ucl.ac.uk> <878s1gqlop.fsf@gmail.com> <8735ronpo0.fsf@ucl.ac.uk> <83lf5gjgtp.fsf@gnu.org> <87eeb8gdbq.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3489"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 05 18:18:27 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBg4h-0000jM-7H for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 18:18:27 +0200 Original-Received: from localhost ([::1]:45080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBg4f-0003QN-9v for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 12:18:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBg45-0002kP-5H for emacs-devel@gnu.org; Thu, 05 Aug 2021 12:17:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45086) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBg44-0003S8-BL; Thu, 05 Aug 2021 12:17:48 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2608 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBg43-0000vA-TL; Thu, 05 Aug 2021 12:17:48 -0400 In-Reply-To: <87eeb8gdbq.fsf@telefonica.net> (message from =?iso-8859-1?Q?=D3scar?= Fuentes on Thu, 05 Aug 2021 16:45:29 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:272101 Archived-At: > From: Óscar Fuentes > Date: Thu, 05 Aug 2021 16:45:29 +0200 > > Eli Zaretskii writes: > > > I'm not sure we've used up the potential of "C-x v v" for Git. > > The "C-x v v" workflow works for Git as far as you use Git as you use > CVS. Which is too little. For example, the pull and push commands are part of every simple Git workflow, but "C-x v v" doesn't support them, AFAIK. If you are going to claim that push and pull are not part of "using Git as you use CVS", then I will claim that your notion of using Git as CVS is pretty useless in practice. > > I'd be interested to see a demonstration of how Magit makes doing some > > fancy Git job without searching the Internet for solutions. But > > please take some really exotic job, not something semi-trivial. > > AFAIK Magit is not advertised as a tool for doing exotic jobs without > prior knowledge. But if that is indeed so, and I still need to search the net for how to do some non-trivial job with Git/Magit, then Magit will be less helpful, because what I will find in my search will mostly be Git commands from the shell prompt, and not their Magit equivalents. > Magit is great at discoverability, ergonomics, and > user-friendliness. This means that the capabilities of the tool are > explicit, you operate the tool with a simple interface and the state you > are operating on is obvious. Compare this with writing commands on the > console (that you previously need to memorize) on a cycle of "see what I > got -> do some change -> see what I got". I'm afraid I'm not following. If I find by searching the net the sequence of Git commands to do some job, I just copy/paste them into the shell window, and that's it. And no need to memorize those commands: the next time I need to do the same job, I do the net search again. Since the search hits the right answers very quickly, this is very adequate for jobs I need to do rarely (which is why I don't remember the commands in the first place). What am I missing? > But I'll try answering your request with two examples. First one: as you > work on some feature you find and fix some typos here and there, or do > some other quick change not directly related to your initial task. You > end with those quick changes mixed with your main task. With Magit, it > is trivial to separately commit the changes: on the Magit status buffer > navigate to the fixed typos, select them as you select a region on > Emacs, press `s' and the selected change goes to the staging area. Do > the same for the rest and commit. You mean, instead of selective "git add" (with or without -i) and/or "git stash"? I'm probably missing something, because I don't see how that's significantly different. > For the second example let's suppose that you implemented a complex > feature as a series of commits on a branch. Those commits reveal all the > gore details of your work: mistakes, backtracks, half-done subtasks, > etc. Things that the rest of the world care nothing about. With Magit > you can easily reorder, split, mix, rewrite, whatever, your commits. I never do that. I commit stuff and merge it exactly as I did originally, and don't care what "the world" thinks about my mistakes and back-tracking. I _want_ to have the original history in the final push. That's why I always almost never use rebase. > >> I do use other version control systems (especially SRC for single file > >> "projects") and so having the same key bindings regardless of VCS is > >> ideal for reducing friction. This is where vc wins. > > > > Yes, and I think it could win more than it does now. In general, the > > adaptation of VC to modern VCSes is IMO incomplete, and we could do > > much better. > > I'm skeptical about this. VC works on some concepts that are hard to > reconciliate with modern VCSes (as long as you want to take advantage of > what those VCSes offer.) The popular workflows are a few, and they cover 85% of typical usage. It is true that at some points of the workflow there could be ambiguity as to what should be the "next action", but that ambiguity could be resolved either by some defcustom or by prompting the users, asking them what would they want to do next from a short list of possibilities. So I think your skepticism is unjustified. How about if we describe one of the simple Git workflows, and see how hard would it be to come up with "C-x v v" support for it in its entirety? > Also, please note that "modern VCSes" are not an homogenous bunch, > there are big differences among them I'd be curious to see those big differences, specifically between Git, Mercurial, and Bazaar. > and those differences will increase with the new wave of VCSes (see > Pijul, for instance.) Let's bother about that when Emacs actually supports those.