Junio C Hamano writes ("Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate"):
> And I do not think we would want "log" or any core side Porcelain
> command to have too many "information losing" options like this
> "truncate refnames down to a point where it is no longer unique and
> meaningful". GUI tools can get away with doing sos because they can
> arrange these truncated labels to react to end-user input (e.g. the
> truncated Tag in the history display of gitk could be made to react
> to mouse-over and pop-up to show a full name, for example), but the
> output from the core side is pretty much fixed once it is emitted.
>
> So my first preference would be to teach gitk such a "please
> clarify" UI-reaction, if it does not know how to do so yet. There
> is no need for a configuration variable anywhere with this approach.
gitk already has a way for the user to find out what the elided tag
names are. The underlying difficulty is that the situation that the
gitk behaviour is designed for (long tag names, perhaps several to a
commit, not particularly interesting), is not applicable to these
particular tags.
Whether the tag is `particularly interesting' depends, as I say, on
both what tree it is in, and on its name. It might be appropriate for
terminal-based tools to highlight these tags too, or show them when
tags are not normally displayed.
`core.interestingTags' ?
> If you do want to add a configuration to show fuller name in the
> tag, which would make it unnecessary for the user to do "please
> clarify, as I am hovering over what I want to get details of"
> action, that may also be a good way to go.
I think in my use case, which I hope to become common within Debian,
this is going to be essential.
> But I think the right
> place to do so would be Edit -> Preferences menu in Gitk, and the
> settings will be stored in ~/.gitk or ~/.config/git/gitk or whatever
> gitk-specific place.
This is not correct, because as I have explained, this should be a
per-tree configuration:
If it can't be a `git config' option, even `git config gui.something',
then I guess I will have to teach gitk to read a config file in
GIT_DIR too. But I think that is silly given that git already has a
config file reading system which handles per-tree configs.
If we can't get agreement from the git-core developers on a config to
be used, and documented, for any tool which has similar behaviour, I
think the right answer is `git config gitk.<something>', which would
be documented in gitk.
Thanks,
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.