Re: [PATCH 11/10] support pager.* for aliases

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2011, 05:43 UTC
Message-ID: <7vaab6552a.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vei0i560a.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 16 quoted lines

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