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?K=C3=A9vin?= Le Gouguec Newsgroups: gmane.emacs.bugs Subject: bug#68183: 28.3; vc-dir fails when I have a certain branch checked out Date: Sun, 17 Mar 2024 19:09:42 +0100 Message-ID: <87ttl43f2x.fsf@gmail.com> References: <8734vici68.fsf@tromey.com> <83y1da17zw.fsf@gnu.org> <87y1dab03x.fsf@tromey.com> <87h6jun400.fsf@gmail.com> <878r3q2jfx.fsf@gmail.com> <877cj6izv7.fsf@gmail.com> <87zfuyrrfz.fsf@gmail.com> <283baeb9-d427-45a3-92d5-5e6c095b87ad@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15353"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Tom Tromey , 68183@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 17 19:11:44 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rluyz-0003kZ-Vd for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Mar 2024 19:11:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rluyk-0002Dj-Do; Sun, 17 Mar 2024 14:11:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rluyj-0002Db-5R for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2024 14:11:25 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rluyi-0003La-Qa for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2024 14:11:24 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rluzK-00008i-Dd for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2024 14:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Mar 2024 18:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68183 X-GNU-PR-Package: emacs Original-Received: via spool by 68183-submit@debbugs.gnu.org id=B68183.1710699092464 (code B ref 68183); Sun, 17 Mar 2024 18:12:02 +0000 Original-Received: (at 68183) by debbugs.gnu.org; 17 Mar 2024 18:11:32 +0000 Original-Received: from localhost ([127.0.0.1]:33470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rluyp-00007P-FH for submit@debbugs.gnu.org; Sun, 17 Mar 2024 14:11:31 -0400 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:57691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rluym-00006z-JM for 68183@debbugs.gnu.org; Sun, 17 Mar 2024 14:11:29 -0400 Original-Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-34175878e30so66771f8f.3 for <68183@debbugs.gnu.org>; Sun, 17 Mar 2024 11:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710698985; x=1711303785; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tgHllJjDGdTcfu9cn5ROhjsUKnkbr0gYKtImvH4YlsQ=; b=WqszNuDh3i0lp3EVyrwzyJtSXRxFUHteX46VcOClgR69Ro+YatsRlPiAVQsyXoROaQ jb8CerJiLrC2DB3lyOK1CXOqsTSwFgiX8AyURltwkBsY0ST05GfTLryrXenDLtzyAdPw s7+AmdrAy82pHbpUdQLHRdni3w6K+zMAQi2IUnjZRgXy1usWU3gVjQz2o10UoOdLsXTI 1VVJf1QUm59zadj8wQB9YKfPtOLGutTNELQ/zvTa+XY/JA4Enp60L0dVe/TpjnMtuQTD ndUCbqilKdhDajbxIZCX5th6GfaIeGrKtCO3MaaIgxwmAt7frY9Jm/KeelnUWyJHW8ql abCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710698985; x=1711303785; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=tgHllJjDGdTcfu9cn5ROhjsUKnkbr0gYKtImvH4YlsQ=; b=Rk9AdYCtq5nnApdHhxxpCyFMQX2/vJnf+N4GPabSfS0uLgLVXlYGKDwWyEV4l4VIE9 GZzAAFuUikqQRNA9KYouNM9wsSjEQJQp29luBjG0iSy3lKur7vVCPHSUa8qhqJqVJ3Mm 2Xjd7dlooKZ9BJ50DcvdZ7sZhLr/KjGvgmT0twH3CuiG+rv+qf9YE+Ie4chJAmPZU9al KI9JjZZQFGaoL6OcvVUU3rcELmqX6m5TbcTu/26qrwqn05Z+JugudvEjep93pYwJvXDX 9nXkCoaVPQLAxBjD8nwPNWUUvICUFJ2D307NFyEG2p9tfRvSLQBgUlhDBfhdWytK4cSk CMxQ== X-Forwarded-Encrypted: i=1; AJvYcCVbf+VSUo9dgzhRbDJiymYjSeD5dT7lFlfyqF7Pk3mMSvwJzMgBGvFPBmYhkInNVn38xeGCpYwdITVa5pQYqSID8GCVPHs= X-Gm-Message-State: AOJu0Yx5XFOHETx3fLAIVz2TZSDSgI1OneghQ25uoEiXWXlxKlEmxPsz 08mY4W+OCKBbOi2ZZ9c1EVlrnBacIpyrEa8PeodfF+PnMegvaxKw X-Google-Smtp-Source: AGHT+IHEdFHBgnwUbtiLCUigOiApjBxvKZJykBfdmD61b2iiguwljiE2xjNrjwvk40C+EmOaALTE/A== X-Received: by 2002:a05:6000:14c:b0:33e:1e2b:3f76 with SMTP id r12-20020a056000014c00b0033e1e2b3f76mr7281329wrx.61.1710698984670; Sun, 17 Mar 2024 11:09:44 -0700 (PDT) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id f10-20020adffcca000000b0033d640c8942sm7991251wrs.10.2024.03.17.11.09.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Mar 2024 11:09:43 -0700 (PDT) In-Reply-To: <283baeb9-d427-45a3-92d5-5e6c095b87ad@gutov.dev> (Dmitry Gutov's message of "Sun, 17 Mar 2024 03:06:36 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281773 Archived-At: Dmitry Gutov writes: >> Re. optimizing the display (which I interpret as reducing redundant >> information): as someone who often works with multiple remotes, seeing >> "Branch: FOO ; Tracking: origin/FOO" is actually useful, so I wouldn't >> want to remove the "tracking" bit unconditionally. OTOH it could surely >> be condensed to a single line, say >> Branch : master (tracking: origin/master) > > Yeah, something like this could work. I was imagining pseudo-graphical > > Branch : master -> origin/master > > , but it's good to have words. Maybe drop the last colon... Right, feels like we have some horizontal space to work with, so we can spend the extra word if it conveys more meaning than an arrow (and yeah, OTOH that last colon does not bring much). >> Likewise, in the local-tracking-branch case, we could go from >> Branch: : vc-dir-bug >> Tracking : master >> Remote : none (tracking local branch) >> to just >> Branch: : vc-dir-bug (tracking: local master) > > I would say that the local-tracking scenario is a minority, and so it's n= ot as important to optimize, but the above makes sense. But the word "local= " is very close to "master", while the latter is a special string which sho= uld probably somehow stand out. So the "unoptimized" version might still ha= ve its advantages: > > Branch: : vc-dir-bug (tracking master) > Remote : none (local branch) That looks sensible. If I were to argue in favor of keeping "local" juxtaposed to the tracking branch, I'd say that in the _absence_ of an explicit qualifier in "Branch: vc-dir-bug (tracking master)", my brain might "default" to assuming we are tracking the remote "master"; a solution to let branch names stand out might then be faces: e.g. vc-git-log-view-mode paints them with change-log-list=E2=80=A6 But I don't know if it's a very powerful argument. >>> Just a thought. Not something that needs to be addressed right now. And= I might as well be off the mark here. >> I agree it's worth thinking about. The Right Solution=E2=84=A2 would pr= obably >> come with user options to let users fine-tune which details they care >> about? It would be interesting to survey Git UIs to see how they >> approach this (FWIW I am partial to Magit's presentation, but I have not >> studied how it handles all the corner cases we considered). > > Magit, meaning just one line for Head: and another for Merge:? So, given =F0=9D=92=B7 =E2=89=94 current branch =F0=9D=93=82 =E2=89=94 branch.=F0=9D=92=B7.merge =F0=9D=93=87 =E2=89=94 branch.=F0=9D=92=B7.remote =F0=9D=93=85 =E2=89=94 branch.=F0=9D=92=B7.pushRemote or remote.pushDefau= lt By default, magit-status shows: "Head:" =F0=9D=92=B7, or the current commit when detached "Merge:" (or "Rebase:") =F0=9D=93=87/=F0=9D=93=82, or just =F0=9D=93=82 if = =F0=9D=93=87 =3D "." "Push:" =F0=9D=93=85/=F0=9D=92=B7, appending "does not exis= t" if applicable (And another header related to tags I'm going to ignore for now) Of note, Magit offers an option (magit-status-headers-hook) to let users control which of these (and more) to display. One of the available headers that is disabled by default shows "Remote: =E2=84=9B " where =E2=84=9B is =F0=9D=93=87, or "origin" if this branch's remote is uns= et or ".", or "the first remote in alphabetic order" if "origin" does not exist. ( Also of note, IMO, is the branch-variable-configuration menu (the magit-branch-configure transient), which looks like this: Configure vc-dir-bug d branch.vc-dir-bug.description unset u branch.vc-dir-bug.merge refs/heads/master branch.vc-dir-bug.remote . r branch.vc-dir-bug.rebase [true|false|default:false] p branch.vc-dir-bug.pushRemote [hirondell|origin|savannah-rw|vps|rem= ote.pushDefault:vps] Configure repository defaults R pull.rebase [true|false|default:false] P remote.pushDefault [hirondell|origin|savannah-rw|vps] b Update default branch Configure branch creation a m branch.autoSetupMerge [always|true|false|default:true] a r branch.autoSetupRebase [always|local|remote|never|default:never] __ (Not pictured: the currently active value in [foo|bar|baz] is highlighted with a face; the keybindings on the left cycle between alternatives) No idea how/where that would fit into VC, but golly is it a neat UI to work with, so I thought it deserved a shout-out. ) >>>>> * maybe the new header deserves a NEWS entry. >>>> Maybe? >>> >>> It wouldn't hurt. Up to you. >>> >>> Anyway, I think the patch is good to go. Please feel free to install it= ; whatever cosmetic changes we might like to add could be done later. >> ACK. I might go a head and install then (after polishing the changelog, >> i.e. re-filling and scrubbing Unicode ellipses) in the spirit of getting >> the original issue fixed; perhaps worth holding off on the NEWS entry >> until we decide how exactly things should look. > > I'm okay with that. (Pushed =F0=9F=93=A8)