Re: [PATCH] Rename git-config-set to git-repo-config

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Thanks; I took yours (big thanks to Tony for teaching us how great topic branches are -- I can just blow my "hold/repoconfig" branch which had only one patch away, apply yours to "master" and merge with other topics), with one minor adjustment.

In "make doc", asciidoc barfs if they do not match, so I adjusted this.

I do not encourge use of Emacs to others; I was using it as an excuse for not debugging nor testing it personally myself ;-).

Depends on what that git-$lang-setup.$lang does, but I am not quite sure. Currently, using git-sh-setup implies you run only from toplevel, with fairly convoluted logic.

I was looking at git-sh-setup does for the last couple of days; and it is really hard to decide what the best approach is to make various pieces subdirectory safe.

Currently git C-level tools works like this:

 - Natively, they work only from the project toplevel.  Period.

 - GIT_DIR defaults to ".git".  GIT_OBJECT_DIRECTORY defaults
   to "$GIT_DIR/objects".

 - If GIT_DIR environment variable does not exist, tools that
   use setup_git_directory() try to find a directory that has a
   subdirectory that looks like a valid GIT_DIR, and chdir() to
   that directory.  They remember the relative path from the new
   cwd() to the original.  If you started from a subdirectory,
   they work at the toplevel, but know where it came from
   e.g. "Documentation/howto/".

   The users of setup_git_directory() are responsible for
   prepending that relative path to user supplied repository
   relative pathnames.  Two functions, prefix_path() and
   get_pathspec(), are supplied to help this process.

   If GIT_DIR environment variable exists, setup_git_directory()
   does not do any ".git/" discovery (there is no point doing so
   because the user told us where it is).  HOWEVER, as a side
   effect of having GIT_DIR, they cannot know where their
   current directory is relative to the project toplevel.  IOW,
   they require to be started at the project toplevel if GIT_DIR
   environment variable exists, and I think this behaviour is
   the only one that makes sense [*1*].

 - The ones that use enter_repo() takes user supplied path,
   chdir() to it and sets GIT_DIR=. environment.  They work in
   naked repository without associated working tree so this is a
   sane behaviour.

 - The ones that use neither assume that they are at the project
   toplevel if they need to access working tree.

Among the scripts, the ones that do _not_ use git-sh-setup but can work in subdirectories work this way:

 - Do not do project toplevel discovery, do not do chdir.

 - Use only tools that use setup_git_directory().

 - If an access to ".git" is needed, find out where it is by
   running "git-rev-parse --git-dir", but _do_ _not_ export it
   as GIT_DIR; otherwise the tools that use
   setup_git_directory() would not work as expected.

 - They do _not_ work from subdirectory if the user has GIT_DIR
   environment set [*2*].

The ones that do use git-sh-setup can use GIT_DIR shell variable given by git-sh-setup, but git-sh-setup does _not_ export it (very important). If GIT_DIR environment was given by the user, the commands would not work from subdirectory because many C-level tools they use have setup_git_directory() internally as mentioned before. Otherwise, GIT_DIR is set to .git by this script, which means these commands can run from the toplevel only.

[Footnote]

*1* This is because GIT_DIR can point at totally out-of-tree. Your working tree can live in tmpfs filesystem and GIT_DIR on safer location. You may lose uncommitted changes in exchange for etter filesystem performance this way.

We _could_ special case when GIT_DIR is set to "/some/path/.git" and "/some/path/" is (grand)*parent directory of the current directory (e.g. /some/path/Documentation/howto), and do the usual chdir() + prefix, but I suspect this leads to more confusion not less. The rules when things work and do not in subdirectories become too complex.

*2* This cannot be helped; see *1* above.