From: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>, Tom Tromey <tom@tromey.com>,
68183@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
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 [thread overview]
Message-ID: <87ttl43f2x.fsf@gmail.com> (raw)
In-Reply-To: <283baeb9-d427-45a3-92d5-5e6c095b87ad@gutov.dev> (Dmitry Gutov's message of "Sun, 17 Mar 2024 03:06:36 +0200")
Dmitry Gutov <dmitry@gutov.dev> 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 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.
>>> 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
(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: ℛ <remote.ℛ.url>"
where ℛ is 𝓇, or "origin" if this branch's remote is unset 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|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.
)
>>>>> * 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 📨)
next prev parent reply other threads:[~2024-03-17 18:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 18:59 bug#68183: 28.3; vc-dir fails when I have a certain branch checked out Tom Tromey
2023-12-31 19:34 ` Eli Zaretskii
2023-12-31 20:14 ` Tom Tromey
2024-01-03 9:46 ` Kévin Le Gouguec
2024-02-12 8:08 ` Kévin Le Gouguec
2024-02-14 19:56 ` Kévin Le Gouguec
2024-03-13 20:03 ` Kévin Le Gouguec
2024-03-15 2:57 ` Dmitry Gutov
2024-03-16 17:56 ` Kévin Le Gouguec
2024-03-17 1:06 ` Dmitry Gutov
2024-03-17 18:09 ` Kévin Le Gouguec [this message]
2024-03-18 15:26 ` Dmitry Gutov
2024-08-07 14:25 ` Kévin Le Gouguec
2024-08-08 0:32 ` Sean Whitton
2024-08-08 7:07 ` Kévin Le Gouguec
2024-08-08 12:02 ` Sean Whitton
2024-08-13 1:32 ` Dmitry Gutov
2024-08-20 6:15 ` Kévin Le Gouguec
2024-08-20 12:15 ` Eli Zaretskii
2024-08-22 7:15 ` Kévin Le Gouguec
2024-08-22 12:46 ` Eli Zaretskii
2024-08-29 15:36 ` Kévin Le Gouguec
2024-08-29 15:46 ` Eli Zaretskii
2024-08-29 16:41 ` Kévin Le Gouguec
2024-08-21 0:42 ` Dmitry Gutov
2024-08-21 1:40 ` Sean Whitton
2024-08-21 7:05 ` Kévin Le Gouguec
2024-08-21 7:59 ` Sean Whitton
2024-08-21 12:29 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttl43f2x.fsf@gmail.com \
--to=kevin.legouguec@gmail.com \
--cc=68183@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).