Jeff King <peff@xxxxxxxx> writes: > On Thu, Aug 18, 2011 at 09:18:49PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> >> > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html