From: Junio C Hamano <junkio@cox.net>
To: Qingning Huo <qhuo@mayhq.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Invoke git-repo-config directly.
Date: Thu, 16 Mar 2006 02:14:52 -0800 [thread overview]
Message-ID: <7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk> (Qingning Huo's message of "Thu, 16 Mar 2006 07:53:24 +0000")
Qingning Huo <qhuo@mayhq.org> writes:
> On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:
>> I think some historical background is in order.
>> ...
> Thanks for the historical background.
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.
next prev parent reply other threads:[~2006-03-16 10:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-14 21:10 [PATCH] Invoke git-repo-config directly Qingning Huo
2006-03-14 21:20 ` Johannes Schindelin
2006-03-14 21:30 ` Qingning Huo
2006-03-14 21:58 ` Linus Torvalds
2006-03-14 22:40 ` Qingning Huo
2006-03-14 23:07 ` Linus Torvalds
2006-03-15 20:40 ` Qingning Huo
2006-03-15 21:33 ` Junio C Hamano
2006-03-15 21:35 ` Junio C Hamano
2006-03-15 22:11 ` Qingning Huo
2006-03-15 22:51 ` Linus Torvalds
2006-03-15 23:35 ` Junio C Hamano
2006-03-16 7:53 ` Qingning Huo
2006-03-16 7:57 ` Junio C Hamano
2006-03-16 8:26 ` Junio C Hamano
2006-03-16 12:53 ` Mark Wooding
2006-03-16 13:53 ` Andreas Ericsson
2006-03-17 2:10 ` Junio C Hamano
2006-03-17 10:51 ` Mark Wooding
2006-03-16 14:27 ` Timo Hirvonen
2006-03-16 14:39 ` Andreas Ericsson
2006-03-16 20:33 ` Qingning Huo
2006-03-16 10:14 ` Junio C Hamano [this message]
2006-03-16 11:55 ` Andreas Ericsson
2006-03-16 19:27 ` Jon Loeliger
2006-03-16 19:32 ` Jon Loeliger
2006-03-16 6:37 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=qhuo@mayhq.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox