Re: [PATCH] Invoke git-repo-config directly.

Qingning Huo <qhuo@mayhq.org> writes:

Sorry, it just occurred to me that I was totally confused, and I apologize for giving only half of the historical background, without giving the "end of the story -- conclusion", which I did not remember until now.

What we ended up deciding after that "My /usr/bin/git is sane but /usr/bin/diff is wrong so I have /home/$u/bin/diff and /home/$u/bin is listed earlier in my $PATH" discussion, as I remember, was this:

 * We expect users to invoke things on the command line via the
   "git" wrapper.  Either having the directory that has our
   "git" in earlier on the PATH, or giving the full path to it
   as the command (your use of alias qualifies as the latter).

 * One of the important things the "git" wrapper does is to
   prefix GIT_EXEC_PATH to the $PATH environment before invoking
   the "git-foo" commands [*1*].  

 * "git-foo" command, if it is written in a scripting language,
   can safely assume "git-bar" is found on the PATH while it is
   executing.  If it is C-level and uses exec[vl]_git_cmd() to
   run the subcommand, it would also work fine (it will use the
   right GIT_EXEC_PATH).

This has a few implications:

 * By doing the above setup, we are effectively punting on the
   original issue.  First of all, it is very inconceivable that
   /usr/bin/git is sane, and /usr/bin/diff is not (git wants a
   working diff after all).  If the user is overriding
   /usr/bin/diff by having a better diff under /home/$u/bin/, he
   could have his own copy of git under /home/$u/bin/ as well
   (more likely, the person with correct privilege to installed
   /usr/bin/git would have replaced faulty /usr/bin/diff).  More
   importantly, when bindir and gitexecdir are split, gitexecdir
   will not be /usr/bin (bindir will be).  It will more likely
   to be /usr/lib/git/exec, and it would contain only git-*
   things; prefixing that directory to PATH would not mask the
   /home/$u/bin/diff or anything else non-git the user wanted to
   mask stuff from /usr/bin with, so the original issue becomes
   moot at that point.

 * Typing "git-foo" on the command line would work most of the
   time, if git is built with gitexecdir set to standard bin
   directory (the way our Makefile is shipped).  git-foo will be
   found on your PATH, and it will find "git-bar" on your PATH.
   However, when we split bindir and gitexecdir, typing
   "git-foo" on the command line without having GIT_EXEC_PATH on
   your PATH would stop working, so users have been encouraged
   to train their fingers to use dashless form ever since
   GIT_EXEC_PATH was introduced [*2*].

 * If "git-foo" invoked from the command line (without necessary
   GIT_EXEC_PATH prefixing done by the "git" wrapper) tries to
   run "git", the right git needs to be found on your PATH,
   otherwise things may not necessarily work (your setup
   violates this).  But people have been encouraged to say "git
   foo" to begin with, so this is probably not a big
   deal. Retraining people to say "git foo" instead of "git-foo"
   is a bigger issue compared to this.

 * If "git foo" is typed on the command line, underlying
   "git-foo" is run with GIT_EXEC_PATH prefixed, so it will find
   "git-bar".  If the script uses "git bar", "git" needs to be
   found either in GIT_EXEC_PATH or on your PATH, since our
   Makefile does not install "git" in gitexecdir.  Right now, we
   have bindir == gitexecdir, so "git bar" in "git-foo" script
   will work fine and this is a non-issue, but when we split
   them, it will break your setup, so we need to address this
   before that happens.

So in short, there are two real issues with your original "git-push misbehaves". One is that it broke because it was spelled with dash. I think "git push" shouldn't misbehave even with your setup, because the "git" wrapper, before it calls "git-push", should set up the PATH so that its exec-path is in front of anything you have in your original PATH (either /usr/bin or ~/opt/bin), and should find the right "git".

And the second issue is the last point in the "implications" list above. You are right, and I stand corrected. Our scripts should consistently use dash form.

One thing that bothers me is that we need to keep encouraging users to use dashless form from the command line, while we update our scripts to use dash form. What a contradicting and confusing situation X-<.

[Footnote]

*1* The "remove prefixing from git.c" patch I sent out earlier tonight is wrong. That's the crucial piece to make this whole setup work.

*2* I think I've been careful enough to use dashless form in the examples I give in my list postings, but I am not sure how successful I have been.