From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Jeff Hostetler <git@jeffhostetler.com>,
git@vger.kernel.org, Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH v2 1/5] core.aheadbehind: add new config setting
Date: Thu, 4 Jan 2018 14:26:04 -0500 [thread overview]
Message-ID: <20180104192604.GA27528@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq1sjgoyph.fsf@gitster.mtv.corp.google.com>
On Wed, Dec 27, 2017 at 09:41:30AM -0800, Junio C Hamano wrote:
> 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.
> 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
next prev parent reply other threads:[~2018-01-04 19:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 19:09 [PATCH v2 0/5] Add --no-ahead-behind to status Jeff Hostetler
2017-12-21 19:09 ` [PATCH v2 1/5] core.aheadbehind: add new config setting Jeff Hostetler
2017-12-21 20:21 ` Igor Djordjevic
2017-12-21 20:43 ` Jonathan Nieder
2017-12-22 18:21 ` Junio C Hamano
2017-12-24 14:33 ` Jeff King
2017-12-27 17:41 ` Junio C Hamano
2018-01-04 19:26 ` Jeff King [this message]
2018-04-03 9:54 ` Lars Schneider
2018-04-03 10:18 ` Ævar Arnfjörð Bjarmason
2018-04-03 11:39 ` Derrick Stolee
2018-04-03 13:47 ` Jeff Hostetler
2018-01-02 21:54 ` Jeff Hostetler
2018-01-02 22:17 ` Jonathan Nieder
2017-12-21 19:09 ` [PATCH v2 2/5] stat_tracking_info: return +1 when branches are not equal Jeff Hostetler
2017-12-21 20:48 ` Jonathan Nieder
2017-12-21 19:09 ` [PATCH v2 3/5] status: add --[no-]ahead-behind to porcelain V2 output Jeff Hostetler
2017-12-21 20:57 ` Jonathan Nieder
2017-12-21 19:09 ` [PATCH v2 4/5] status: update short status to use --no-ahead-behind Jeff Hostetler
2017-12-21 19:09 ` [PATCH v2 5/5] status: support --no-ahead-behind in long format Jeff Hostetler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180104192604.GA27528@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeffhost@microsoft.com \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).