From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#68183: 28.3; vc-dir fails when I have a certain branch checked out Date: Mon, 18 Mar 2024 17:26:11 +0200 Message-ID: <06a946b4-b06a-4e10-93d5-b6d6b8bd9fcf@gutov.dev> 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> <87ttl43f2x.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24973"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , Tom Tromey , 68183@debbugs.gnu.org, Juri Linkov To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 18 16:32:48 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 1rmEyl-0006E7-6p for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Mar 2024 16:32:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmEyZ-0006gh-Kl; Mon, 18 Mar 2024 11:32:35 -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 1rmEyP-0006aa-Og for bug-gnu-emacs@gnu.org; Mon, 18 Mar 2024 11:32:30 -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 1rmEyP-00050U-Gn for bug-gnu-emacs@gnu.org; Mon, 18 Mar 2024 11:32:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rmEz0-0001kY-6n for bug-gnu-emacs@gnu.org; Mon, 18 Mar 2024 11:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Mar 2024 15:33: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.17107759806719 (code B ref 68183); Mon, 18 Mar 2024 15:33:02 +0000 Original-Received: (at 68183) by debbugs.gnu.org; 18 Mar 2024 15:33:00 +0000 Original-Received: from localhost ([127.0.0.1]:58764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmEyv-0001kE-0v for submit@debbugs.gnu.org; Mon, 18 Mar 2024 11:33:00 -0400 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:51235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmEyr-0001jd-Bo for 68183@debbugs.gnu.org; Mon, 18 Mar 2024 11:32:56 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D892032009F9; Mon, 18 Mar 2024 11:26:17 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 18 Mar 2024 11:26:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1710775577; x=1710861977; bh=IYmDaIijhLispHm+ouMrC6ZBDPUuO/FdUTBlDDe3Pu0=; b= hD3qox1cafQdXhzjazx9bNjOjrLQ6huvAslLnswlRnf5Hv6HtP1a5BTaDiC6bHSp XfbG5I9DnCM1JaRqRXg9vuMiBa+B7EOdIr23qz8HYCSyUWOwjcDjfU5fNQYSXXWq 7d5/cvMpo1WayxSEYe89gVMvIwZldMPnq5JTz0Ds2F03NYMS+IK8AIAicAhSSchz SVxn9OUA586ZrEAnUvZZvyo6aZopUnHMyP74dXbiDv11+scuygkP6dRFTGw5ozFk NWsidOzDxmTOlcReSsbhBmtqECARQ4oJw6d4jPska5ixQjEsDcy1PULJAm1F6W5S VMUDTLu81JrrO1P0AtqwRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1710775577; x= 1710861977; bh=IYmDaIijhLispHm+ouMrC6ZBDPUuO/FdUTBlDDe3Pu0=; b=a bu5YvyOtrl3VQxI8IsP+2tveav5a6V9oP60kVOTHcmnuel2WvIaEX43rBt8a3MAt onpjL29S+hcOwXEAyO7qBrdIbTWaERaBq57lGzGKxxvI7+Dx7FnuDozB0Pdc8Bbs SBVNxC1ZGmlov3m+eanFF2FnsfnCamy1mN/iI9cD3hcIm1IAm6L0VaTDeQE8IyTT 9tddynZGr/7oNCHdgR+sWnQ+cbhNmYHjBLnbn0ijVweaFr+mYYoJqLtJnZup2eAw INdoirEWpUhcAd5kdAvCKdrJvEg4ZDzKZTuqSWX/Sj/5ExJAeBET7DIQ6sNITX/x 2YejwVLD4CE3mM5CbyH2g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrkeejgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeegleefteekgffhvdfhtdegveevveetteegteevgeettdehhfdukeetheffueek keenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 18 Mar 2024 11:26:14 -0400 (EDT) Content-Language: en-US In-Reply-To: <87ttl43f2x.fsf@gmail.com> 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:281807 Archived-At: On 17/03/2024 20:09, KΓ©vin Le Gouguec wrote: >> I would say that the local-tracking scenario is a minority, and so it's not 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 should probably somehow stand out. So the "unoptimized" version might still have 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… > > But I don't know if it's a very powerful argument. I figured that when "local" is on the next line already, it's easy enough to notice. Anyway, it's up to you, I think. >>>> 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β„’ would probably >>> 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 > > 𝒷 ≔ current branch > 𝓂 ≔ branch.𝒷.merge > 𝓇 ≔ branch.𝒷.remote > 𝓅 ≔ branch.𝒷.pushRemote or remote.pushDefault > > By default, magit-status shows: > > "Head:" 𝒷, or the current commit when detached > "Merge:" (or "Rebase:") 𝓇/𝓂, or just 𝓂 if 𝓇 = "." > "Push:" 𝓅/𝒷, appending "does not exist" if applicable So Magit also prints just "master" is it's a local tracking branch and something like "origin/master" when it belongs to a remote? Going with that approach, we'd seem justified to print Branch: : vc-dir-bug (tracking master) in the former case and Branch: : vc-dir-bug (tracking origin/master) in the latter. > (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: β„› " > > where β„› is 𝓇, or "origin" if this branch's remote is unset or ".", or > "the first remote in alphabetic order" if "origin" does not exist. Meaning it prepends the remote's url with remote's name, if that line is configured to be shown. We could do that too. > ( > 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|remote.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. > ) Magit is definitely a great UI to learn Git's capabilities. >>>>>> * 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 πŸ“¨) Thanks!