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

Johannes Schindelin [off-list ref] writes:

Well, there are differences:

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.

- I did not adjust the length of the "=====" line in the dox,

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

Well, I don't use Emacs any longer, since it was such a hassle to install 
it on every machine. I still like it, though.

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

As for git-mv: looks like we need a "git-perl-setup.perl", right?

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.