On Tue, Apr 03 2018, Lars Schneider wrote: >> On 04 Jan 2018, at 20:26, Jeff King <peff@xxxxxxxx> wrote: >> >> On Wed, Dec 27, 2017 at 09:41:30AM -0800, Junio C Hamano wrote: >> >>> Jeff King <peff@xxxxxxxx> 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 :-) It's in the gvfs branch of git@xxxxxxxxxx:Microsoft/git.git, i.e. it's not in Git for Windows, but used in Microsoft's own in-house version used for Windows.git. I may be misunderstanding this feature, but my impression was that it was a kludge as a workaround until the commit graph code landed, because once we have that then surely we can just cheaply report the actual (or approximate?) number in the common case, but of course it may still be slow if your commit graph file is out of date.
