Ian Jackson [off-list ref] writes:
quoted
I think the two things I found weird were:
- it's in the "log" section, which makes me think it's an option for
git-log. But it's not. I'm not sure what the _right_ section is, but
hopefully it would make it clear that this is command-agnostic.
Something like "gui.abbrevTags" might be OK (and as you note, has
precedence). But of course it's possible that a command like "tig"
could learn to support it. I'm not sure if that counts as a GUI or
not. :)
I don't really have an opinion about the name. gui.abbrevTags would
be a possibility. (It's a bit odd that implicitly, the default would
be `*'.)
I have trouble with both "log" and "abbrev" in the name. Perhaps I
am biased by our recent discussion on a feature in the core that we
use the word "abbrev" to describe, but I fear that most Git users,
when told the word, would imagine the act of shortening 40-hex full
object name down to shorter but still unique prefix, not the "this
refname is too long, so let's show only the first few letters in GUI
label".
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.
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. 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.
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 [off-list ref] 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.