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@xxxxxxxxxxxxxxxxxxxxxx> 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.