From: Marc Branchaud <marcnarc@xiplink.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: Michael Haggerty <mhagger@alum.mit.edu>, git@vger.kernel.org
Subject: Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
Date: Tue, 20 Dec 2016 17:53:05 -0500 [thread overview]
Message-ID: <b19e76cb-8584-186b-512b-e53ef263f7a7@xiplink.com> (raw)
In-Reply-To: <20161220221719.GB22566@fergus.ozlabs.ibm.com>
On 2016-12-20 05:17 PM, Paul Mackerras wrote:
> On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote:
>> On 2016-12-19 11:44 AM, Michael Haggerty wrote:
>>> This patch series changes a bunch of details about how remote-tracking
>>> references are rendered in the commit list of gitk:
>>
>> Thanks for this! I like the new, compact look very much!
>>
>> That said, I remember when I was a new git user and I leaned heavily on gitk
>> to understand how references worked. It was particularly illuminating to
>> see the remote references distinctly labeled, and the fact that they were
>> "remotes/origin/foo" gave me an Aha! moment where I came to understand that
>> the refs hierarchy is more flexible than just the conventions coded into git
>> itself. I eventually felt free to create my own, private ref hierarchies.
>>
>> I am in no way opposed to this series. I just wanted to point out that
>> there was some utility in those labels. It makes me think that it might be
>> worthwhile for gitk to have a "raw-refs" mode, that shows the full
>> "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It
>> could be a useful teaching tool for git.
>
> Do you think we should have a checkbox in the preferences dialog to
> select whether to display the long form or the short form?
Mmmm, more knobs!
No, I don't think that's necessary. Such a setting would probably just
confuse people. Plus it's not something anyone is likely to want to
change anyway. Maybe if there were an "Advanced" tab in the settings
dialog, but even then it seems like overkill.
I suspect there are better ways to teach people about the refs hierarchy
than cluttering up gitk. These may even already exist -- I've been a
git user for 8 years now, so I'm sure my perspective of the learning
curve is skewed.
M.
next prev parent reply other threads:[~2016-12-20 23:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
2016-12-19 16:45 ` [PATCH 01/13] gitk: when processing tag labels, don't use `marks` as scratch space Michael Haggerty
2016-12-19 16:45 ` [PATCH 02/13] gitk: keep track of tag types in a separate `types` array Michael Haggerty
2016-12-19 16:45 ` [PATCH 03/13] gitk: use a type "tags" to indicate abbreviated tags Michael Haggerty
2016-12-19 16:45 ` [PATCH 04/13] gitk: use a type "mainhead" to indicate the main HEAD branch Michael Haggerty
2016-12-19 16:45 ` [PATCH 05/13] gitk: fill in `wvals` as the tags are first processed Michael Haggerty
2016-12-19 16:45 ` [PATCH 06/13] gitk: simplify regexp Michael Haggerty
2016-12-19 16:45 ` [PATCH 07/13] gitk: extract a method `remotereftext` Michael Haggerty
2016-12-19 16:45 ` [PATCH 08/13] gitk: only change the color of the "remote" part of remote refs Michael Haggerty
2016-12-19 16:45 ` [PATCH 09/13] gitk: shorten labels displayed for modern remote-tracking refs Michael Haggerty
2016-12-19 16:45 ` [PATCH 10/13] gitk: use type "remote" for remote-tracking references Michael Haggerty
2016-12-19 16:45 ` [PATCH 11/13] gitk: introduce a constant otherrefbgcolor Michael Haggerty
2016-12-19 16:45 ` [PATCH 12/13] gitk: add a configuration setting `remoterefbgcolor` Michael Haggerty
2016-12-19 16:45 ` [PATCH 13/13] gitk: change the default colors for remote-tracking references Michael Haggerty
2016-12-19 22:53 ` [PATCH 00/13] gitk: tweak rendering of " Philip Oakley
2016-12-20 8:03 ` Michael Haggerty
2016-12-20 15:01 ` Marc Branchaud
2016-12-20 22:17 ` Paul Mackerras
2016-12-20 22:53 ` Marc Branchaud [this message]
2016-12-21 0:05 ` Michael Haggerty
2016-12-21 19:07 ` Marc Branchaud
2016-12-22 8:15 ` Michael Haggerty
2017-01-09 22:03 ` Marc Branchaud
2017-02-06 17:13 ` Marc Branchaud
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: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b19e76cb-8584-186b-512b-e53ef263f7a7@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=paulus@ozlabs.org \
/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://80x24.org/mirrors/git.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).