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

Jeff King [off-list ref] writes:

On Thu, Aug 18, 2011 at 09:18:49PM -0700, Junio C Hamano wrote:

quoted

Jeff King [off-list ref] writes:

quoted

quoted

quoted

Until this patch, doing something like:

  git config alias.foo log
  git config pager.foo /some/specific/pager

would not respect pager.foo at all.

Is it a good thing? Looks too confusing and I am having a hard time to
decide if this is "just because we could" or "because we need to be able
to do this for such and such reasons".

I don't have a particular use for it myself. However, I don't see what's
confusing about it. Would would you expect the above commands to do with
respect to paging?

The reason I found it confusing was that I expected the "log" command that
is run as the expansion of the alias to be oblivious to the fact that the
end user called it "foo", and ignore anything specific to "foo", including
"pager.foo".

I think of it this way:

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.