These patches are designed to make people who want the pager.<cmd> configuration to be more reliable a little happier. More importantly, they bring the setup procedure closer to doing the Right Thing™. More precisely: The pager configuration procedure does not always do as much as one would like: A. Unless one runs check_pager_config() first, the pager.<cmd> configuration is ignored. The setup procedure does not run check_pager_config() for commands that do not use RUN_SETUP. B. Unless one runs setup_repository_gently() first, functions that check configuration expect to find configuration in ./.git/config. This is wrong for two reasons: some commands should ignore the per-repository configuration, and most commands should be walking parent parent directories to find an appropriate .git or foo.git dir. The upshot is that the per-repository configuration is ignored for pager.<cmd> and core.pager when git is run from the toplevel of a repository. These patches are a modest attempt to start to ameliorate these problems. Patches 1, 2, and 4 introduce new tests to make sure we are not making things worse. Patch 3 delays startup of the pager. By the time we actually need to start a pager for commands with the RUN_SETUP option, the .git directory will already have been found, addressing problem (B) for those commands. Patches 5 and 6 are something of a trojan horse: they introduce infrastructure that I expect to be more widely useful after this modest patch series. That infrastructure is a collection of global variables representing the state of the current repository, for built-in commands only (for now). The main benefit now is that it lets us pass more data to builtins without changing the builtin API. Patches 7 gives builtins the option to search for a repository early even if they do not require a repository to work. The benefits of patch 3 will accrue to such commands just as though they used RUN_SETUP. Patch 8 addresses problem (A) for builtins using this new RUN_SETUP_GENTLY option. And patch 9 is an example command taking advantage of the opportunity. I don’t imagine anyone was eagerly awaiting the ability to make their ‘git config’ automatically paginate. The secondary benefits (especially UI consistency) are in my opinion more important. This series would not be possible without the hard work of Nguyễn Thái Ngọc Duy. It consists mostly of patches by him. A footnote [1] contains some context if you would like it. Thoughts? Jonathan Nieder (4): t7006: GIT_DIR/config should be honored in subdirs of toplevel t7006: test pager configuration for several git commands t7006: test pager.<cmd> configuration builtin: check pager.<cmd> configuration if RUN_SETUP_GENTLY is used Nguyễn Thái Ngọc Duy (5): builtins: do not commit pager choice early builtin: introduce startup_info struct builtin: remember whether repository was found builtin: Support RUN_SETUP_GENTLY to set up repository early if found config: run setup before commiting pager choice builtin/config.c | 6 +- cache.h | 6 ++ environment.c | 1 + git.c | 23 +++++-- setup.c | 12 ++++- t/t7006-pager.sh | 168 +++++++++++++++++++++++++++++++++++++++++------------- 6 files changed, 165 insertions(+), 51 deletions(-) [1] I warned that something like this was coming at <http://thread.gmane.org/gmane.comp.version-control.git/144090>. I will send a rebased version of the rest of the nd/setup series to the list as a follow-up. But beware: after perhaps introducing all kinds of bugs through repeated rebasing, I didn’t give the later patches of the series another glance. -- 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