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 14:01:38 +0300 Message-ID: <83lf5gjgtp.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31294"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eric S Fraga Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 05 13:04:15 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 1mBbAc-0007wW-RK for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 13:04:14 +0200 Original-Received: from localhost ([::1]:48308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBbAa-0002s9-RU for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 07:04:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35846) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBb8J-0001OG-76 for emacs-devel@gnu.org; Thu, 05 Aug 2021 07:01:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33776) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBb8G-0006bh-Sk; Thu, 05 Aug 2021 07:01:50 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3008 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 1mBb8F-0008Sf-JH; Thu, 05 Aug 2021 07:01:48 -0400 In-Reply-To: <8735ronpo0.fsf@ucl.ac.uk> (message from Eric S Fraga on Thu, 05 Aug 2021 11:37:03 +0100) 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:272083 Archived-At: > From: Eric S Fraga > Date: Thu, 05 Aug 2021 11:37:03 +0100 > > On Thursday, 5 Aug 2021 at 19:23, Tim Cross wrote: > > I'm not sure how easily you could do a git interface based around > > dired-style UI design which provides much more than the vc-* interface > > already provides. > > Yes, that's probably the case. I use vc for most of the simple > activities (diffs, simple commits, viewing the log, pushing/fetching) > but fall back to magit for selective commits and branching. I'm not sure we've used up the potential of "C-x v v" for Git. It currently doesn't even fully support the simplest workflow with Git, only going as far as making a local commit. (I tried to suggest a better "next action" heuristics some moons ago, but couldn't get the involved parties to agree.) If and when we have the basic Git workflow covered, we could perhaps try implementing some less frequent variants using some combination of heuristics and prompting the user. FWIW, when I need to do something with Git that I do rarely and therefore don't really remember how it's done, I just search the Internet. There's so much stuff there about every single Git command and Git-related issue that I usually find the answer in a few seconds. IME, the Git man pages are worthless unless you know exactly which command you want to use, so I almost never use the docs which come with Git. 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. > 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.