From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org,
"Steffen Daode Nurpmeso" <sdaoden@googlemail.com>,
"Ingo Brückl" <ib@wupperonline.de>
Subject: Re: [PATCH 11/10] support pager.* for aliases
Date: Thu, 18 Aug 2011 22:43:57 -0700 [thread overview]
Message-ID: <7vaab6552a.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7vei0i560a.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Thu, 18 Aug 2011 22:23:33 -0700")
Junio C Hamano <gitster@pobox.com> writes:
>> If the user thinks of the alias as just another form of "log", then we
>> do the right thing: we use log's pager config by default, and respect
>> pager.log. They never set pager.foo, because that is nonsensical in
>> their mental model.
>>
>> If the user thinks of the alias as its own command, then they would
>> expect pager.foo to work. And it does what they expect.
>>
>> But like I said, I don't personally plan on using this. It was just the
>> only semantics that really made sense to me,...
>
> I can see that argument, but once you start paying attention to "*.foo",
> you have to keep supporting that forever, and also more importantly, you
> need to worry about interactions between "*.foo" vs "*.log". Which one
> should win? Should they combine if both are defined? My "looks confusing"
> includes that can of worms.
Actually there is another thing that I think is much worse. If the user is
trained to think of the alias as its own command by seeing pager.foo to
work as you described, you cannot blame them if they would also expect
these to work, in the sense that only "foo.*" and "bar.*" respectively
would take effect, and they would override "log.*":
[alias]
foo = log
bar = !sh -c 'log "$@"' -
[log]
date = default
[foo]
date = iso
[bar]
date = relative
I do not think we want to go there.
next prev parent reply other threads:[~2011-08-19 5:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 4:58 [PATCH 0/10] color and pager improvements Jeff King
2011-08-18 5:00 ` [PATCH 01/10] t7006: modernize calls to unset Jeff King
2011-08-18 21:05 ` Junio C Hamano
2011-08-18 5:01 ` [PATCH 02/10] test-lib: add helper functions for config Jeff King
2011-08-18 21:10 ` Junio C Hamano
2011-08-18 5:02 ` [PATCH 03/10] t7006: use test_config helpers Jeff King
2011-08-18 5:02 ` [PATCH 04/10] setup_pager: set GIT_PAGER_IN_USE Jeff King
2011-08-18 5:03 ` [PATCH 05/10] diff: refactor COLOR_DIFF from a flag into an int Jeff King
2011-08-18 5:03 ` [PATCH 06/10] git_config_colorbool: refactor stdout_is_tty handling Jeff King
2011-08-18 5:04 ` [PATCH 07/10] color: delay auto-color decision until point of use Jeff King
2011-08-18 21:59 ` Junio C Hamano
2011-08-18 22:28 ` Jeff King
2011-08-18 5:04 ` [PATCH 08/10] config: refactor get_colorbool function Jeff King
2011-08-18 5:05 ` [PATCH 09/10] diff: don't load color config in plumbing Jeff King
2011-08-18 5:05 ` [PATCH 10/10] want_color: automatically fallback to color.ui Jeff King
2011-09-04 2:36 ` Martin von Zweigbergk
2011-09-04 12:53 ` Jeff King
2011-09-05 11:31 ` Steffen Daode Nurpmeso
2011-08-18 21:58 ` [PATCH 0/10] color and pager improvements Jeff King
2011-08-18 21:59 ` [PATCH 11/10] support pager.* for aliases Jeff King
2011-08-18 22:54 ` Junio C Hamano
2011-08-19 3:37 ` Jeff King
2011-08-19 4:18 ` Junio C Hamano
2011-08-19 4:40 ` Jeff King
2011-08-19 5:23 ` Junio C Hamano
2011-08-19 5:43 ` Junio C Hamano [this message]
2011-08-19 8:30 ` Jeff King
2011-08-18 22:01 ` [PATCH 12/10] support pager.* for external commands Jeff King
2011-08-18 22:56 ` Junio C Hamano
2012-02-12 0:46 ` Ævar Arnfjörð Bjarmason
2012-02-14 19:13 ` Jeff King
2011-08-18 22:33 ` [PATCH 0/10] color and pager improvements Ingo Brückl
2011-08-18 22:46 ` Jeff King
2011-08-19 6:34 ` Ingo Brückl
2011-08-25 20:25 ` Jeff King
2011-08-18 21:59 ` Steffen Daode Nurpmeso
2011-08-18 22:02 ` Junio C Hamano
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=7vaab6552a.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ib@wupperonline.de \
--cc=peff@peff.net \
--cc=sdaoden@googlemail.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).