From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: On the adoption of transient.el Date: Thu, 05 Aug 2021 16:45:29 +0200 Message-ID: <87eeb8gdbq.fsf@telefonica.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:N2QPnQTRli5AAC13SeQ7nT/RPbw= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 05 16:49:29 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 1mBegb-0006tF-KB for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 16:49:29 +0200 Original-Received: from localhost ([::1]:43452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBega-0007gE-8U for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 10:49:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBed2-0003s7-Vg for emacs-devel@gnu.org; Thu, 05 Aug 2021 10:45:48 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:44566) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBecx-0000nD-Ff for emacs-devel@gnu.org; Thu, 05 Aug 2021 10:45:48 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mBect-0001bw-Ix for emacs-devel@gnu.org; Thu, 05 Aug 2021 16:45:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_C=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:272092 Archived-At: 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. > 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. 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". However, you still need to know the basic concepts of Git to use Magit. 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. 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. Thanks to this you can end with a tidy series of commits, which are much more adequate for the public consumption (suppossing that the public is more interested on how the feature is implemented that on your personal method of writing code.) >> 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.) Also, please note that "modern VCSes" are not an homogenous bunch, there are big differences among them, and those differences will increase with the new wave of VCSes (see Pijul, for instance.)