From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Markus Hitter <mah@jump-ing.de>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate
Date: Tue, 8 Nov 2016 13:42:52 +0000 [thread overview]
Message-ID: <22561.54876.646018.985175@chiark.greenend.org.uk> (raw)
In-Reply-To: <0d7ff8e5-230a-c6e1-6663-eaecee5d5620@jump-ing.de>
Markus Hitter writes ("Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate"):
> TBH, I see a violation of tool independence with the choice of
> preference storage. Abbreviation of tags isn't a property of the
> repository, but a pure visual thing (screen real estate, whatever),
> so it should be handled by the tool doing the visuals, only.
As I explained in my cover letter, the set of tags which are important
enough not to abbreviate, even if they would normally be abbreviated,
is indeed a property of the repository.
The alternative would be for a tool like gitk to grow an
ever-increasing set of heuristics. Or, worse, for a tool like dgit
(which knows that archive/* are special) to edit the user's personal
gitk settings.
> Your use case looks like a nice opportunity for
>
> - adding a Gitk user preference on how long displayed tags are
> allowed to be (instead of distinguishing between abbreviated and
> unabbreviated ones; set it to 999 for your use case) and/or
This would be wrong, because it's only certain tags that ought not to
be abbreviated. The right way to identify those tags is by 1. what
repo they are in 2. what their name is. (It might be possible to
identify them by content or something - for example, the interesting
archive/* tags all refer to commits whose trees contain debian/ - but
that is getting quite out of hand.)
What you propose are possible general improvements to the abbreviation
system in gitk. But they do not address the fundamental point that
some tags are much more interesting than others. It is this latter
point that I am trying to deal with.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
prev parent reply other threads:[~2016-11-08 13:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-08 0:52 [PATCH 0/6] Provide for config to specify tags not to abbreviate Ian Jackson
2016-11-08 0:52 ` [PATCH GITK 1/6] gitk: Internal: drawtags: Abolish "singletag" variable Ian Jackson
2016-11-08 0:52 ` [PATCH GITK 2/6] gitk: Internal: drawtags: Idempotently reset "ntags" Ian Jackson
2016-11-08 0:52 ` [PATCH GITK 3/6] gitk: drawtags: Introduce concept of unabbreviated marks Ian Jackson
2016-11-08 0:52 ` [PATCH GITK 4/6] gitk: Provide for config to specify tags not to abbreviate Ian Jackson
2016-11-08 0:52 ` [PATCH 5/6] config docs: " Ian Jackson
2016-11-08 2:28 ` Jacob Keller
2016-11-08 10:51 ` Ian Jackson
2016-11-08 21:57 ` Jeff King
2016-11-09 1:41 ` Ian Jackson
2016-11-09 5:55 ` Junio C Hamano
2016-11-09 10:51 ` Ian Jackson
2016-11-09 23:13 ` Junio C Hamano
2016-11-09 23:31 ` Ian Jackson
2016-11-10 0:36 ` Markus Hitter
2016-11-08 0:54 ` [PATCH 0/6] " Ian Jackson
2016-11-08 9:19 ` Markus Hitter
2016-11-08 13:42 ` Ian Jackson [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22561.54876.646018.985175@chiark.greenend.org.uk \
--to=ijackson@chiark.greenend.org.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mah@jump-ing.de \
--cc=paulus@samba.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.