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: Sat, 14 Aug 2021 14:54:24 +0200 Message-ID: <87wnoofapr.fsf@telefonica.net> References: <877di4on3d.fsf@posteo.net> <87im1oy6mw.fsf@posteo.net> <87czquisme.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14376"; 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:+kgkD27zefpHZbHILmhye5U67lc= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 14 14:55:45 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 1mEtCS-0003W3-Vb for ged-emacs-devel@m.gmane-mx.org; Sat, 14 Aug 2021 14:55:44 +0200 Original-Received: from localhost ([::1]:35806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEtCS-0004pV-0r for ged-emacs-devel@m.gmane-mx.org; Sat, 14 Aug 2021 08:55:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEtBQ-00043d-QM for emacs-devel@gnu.org; Sat, 14 Aug 2021 08:54:40 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:59742) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEtBP-0001Vj-71 for emacs-devel@gnu.org; Sat, 14 Aug 2021 08:54:40 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mEtBL-00026e-7b for emacs-devel@gnu.org; Sat, 14 Aug 2021 14:54:35 +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: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:272385 Archived-At: Arthur Miller writes: > Jonas Bernoulli writes: > >>> I have to run Magit than bb and than Magit will offer a completing >>> read which will pop the asked Helm interface. To me this is not a >>> straightforward enough >> >> (global-set-key [f1] 'magit-checkout) >> >> Also you generally don't have to "run Magit" and can just use "C-x M-g" >> and in file-visiting buffers also "C-c M-g". > > Hi Jonas, I have tried your magit-checkout now. It does not really do > what I had in mind. It seems to just be a wrapper around git checkout, > and similar to git checkout gives error if there are unstaged changes. > > What I wanted was a fast straightforward branch switcher, no questions > asked. > > The strategy is to stash save all buffers belonging to the project, > stash everything, inclusive untracked files, and than checkout to the > other branch. When checked back, the stash is applied back. I don't know > if you have something like that in magit or if it is something generally > desirable, but I always wanted something simple and dirty to be able to > switch fast when I need it. How would Magit know that when you "return back" to a branch it must apply a certain stash? It seems to me that you are asking for some Work-In-Progress management system, which use branches instead of stashes. IIRC there are some Magit extensions for this and even creating your own doesn't seem difficult, but IMHO your use case, in the way you describe it, has dubious applications in general. For starters, the part about automatically stashing untracked files, I have seem cases where it would stash gigabytes of build products.