On Tue, Nov 08, 2016 at 10:51:33AM +0000, Ian Jackson wrote:
> Yes, I agree that it does seem weird. But the alternatives seem
> worse. I think it's probably best if options like this (currently
> only honoured by out-of-core tools but of general usefulness) are
> collected together here.
>
> There is a precedent: `git config gui.encoding' is, according to the
> documentation, honoured only by git-gui and gitk.
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.
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. :)
- 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.
-Peff
