Subject: [PATCH/RFC 0/9] Setup cleanup, chapter one

From: Jonathan Nieder <[email-masked]>
Date: Mon, 12 Apr 2010 21:11:54 -0500

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.