> On 04 Jan 2018, at 20:26, Jeff King <p...@peff.net> wrote: > > On Wed, Dec 27, 2017 at 09:41:30AM -0800, Junio C Hamano wrote: > >> Jeff King <p...@peff.net> writes: >> >>> I, too, had a funny feeling about calling this "core". But I didn't have >>> a better name, as I'm not sure what other place we have for config >>> options that cross many command boundaries. "diff" and "status" don't >>> seem quite right to me. While you can argue they are subsystems, it >>> seems too easy for users to confuse them with the commands of the same >>> names. >>> >>> Maybe there should be a "ui.*" config hierarchy for these kinds of >>> cross-command interface options? >> >> I had an impression that ui.* was primarily pretty-printing, >> colouring and things of such nature. > > I didn't think we had a "ui.*" so far. We have "color.ui" and > "column.ui", but I think that's it. > > At any rate, my intent was to consider this a "ui" issue, in that we are > deciding how the ahead/behind hints should be shown to the user. > >> I do not think it is such a >> bad idea to honor a status.frotz variable that affects how (e.g. to >> what degree of detailedness) status on frotz are reported in Git >> subcommands other than 'git status' if they report the same sort of >> information on 'frotz' that 'git status' makes. > > Is ahead/behind uniquely attached to git-status? IOW, could this be called > "branch.aheadbehind" and git-status respects it? It seems like putting > it in status introduces a weird asymmetry. > > I buy the argument more that "status" here is not "this is a git-status > config option", but "this config section encompasses various things > about the status of a repository reported by many commands". But then > it's kind of funny to have many of the existing options there that > really are specific to git-status. > > In can be both of those things, of course, but then it becomes less > clear to the user which config options affect which command. > > I dunno. It is probably not _that_ big a deal, and I can live with it > wherever. But Git has a reputation for having inconsistencies and weird > asymmetries in its UI, so I like to give some thought to squashing them > preemptively.
What is the state of this series? I can't find it in git/git nor in git-for-windows/git. I think Stolee mentioned the config in his Git Merge talk [1] and I was about to test it/roll it out :-) - Lars [1] https://youtu.be/oOMzi983Qmw
