Jeff King writes ("Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate"):
> Yeah, I think git's config system was always designed to carry options
> for porcelains outside of git-core itself. So your new option fits into
> that.
Good, thanks.
> 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 `*'.)
> - The description talks about tag abbreviation, but doesn't really
> define it. Not being a gitk user, it was hard for me to figure out
> whether this was even relevant. Does it mean turning
> "refs/tags/v1.0" into "1.0"? From the rest of the series, it sounds
> like no. That should be more clear from the documentation.
I can do that, sure.
By default, gitk doesn't like to use much screen real estate for tags.
If there are long tag names, or many tags, it shows them all as a
single small indication saying just `<tag...|' or whatever with the
literal `tag...', not with the tag value.
Maybe a better name would be
gui.alwaysShowTags
?
I'm happy to be just told what the name ought to be, if the gitk and
git maintainers can agree. It seems largely a matter of taste.
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.