Re: [PATCH v2 1/5] core.aheadbehind: add new config setting

From: Jeff King <peff@peff.net>
Date: Jan 4, 2018, 19:26 UTC
Message-ID: <20180104192604.GA27528@sigill.intra.peff.net>
In-Reply-To: <xmqq1sjgoyph.fsf@gitster.mtv.corp.google.com>

On Wed, Dec 27, 2017 at 09:41:30AM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> Jeff King <peff@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.

Show 5 quoted lines

> 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.

-Peff