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