[PATCH] Invoke git-repo-config directly.

The system have GNU git installed at /usr/bin/git.  I installed git-core
to ~/opt/bin.  ~/opt/bin is in my PATH, but is after /usr/bin.  I have
set alias git="$HOME/opt/bin/git".

git-push and git-pull behaves strangely, because they call "git
repo-config", which runs /usr/bin/git.  Using "git-repo-config" directly
fixed the problem.

Signed-off-by: Qingning Huo <redacted>

---

 git-pull.sh     |    4 ++--
 git-sh-setup.sh |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

a0194fff002cb12ac58b202201d387f8ea55b225

diff --git a/git-pull.sh b/git-pull.sh
index 6caf1aa..e32e2b0 100755
--- a/git-pull.sh
+++ b/git-pull.sh

@@ -70,7 +70,7 @@ case "$merge_head" in
 	exit 0
 	;;
 ?*' '?*)
-	var=`git repo-config --get pull.octopus`
+	var=`git-repo-config --get pull.octopus`
 	if test '' = "$var"
 	then
 		strategy_default_args='-s octopus'

@@ -79,7 +79,7 @@ case "$merge_head" in
 	fi
 	;;
 *)
-	var=`git repo-config --get pull.twohead`
+	var=`git-repo-config --get pull.twohead`
 	if test '' = "$var"
 	then
 		strategy_default_args='-s recursive'

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 025ef2d..12f5ede 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh

@@ -41,7 +41,7 @@ then
 	: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
 
 	# Make sure we are in a valid repository of a vintage we understand.
-	GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
+	GIT_DIR="$GIT_DIR" git-repo-config --get core.nosuch >/dev/null
 	if test $? = 128
 	then
 	    exit

-- 
1.2.4.ga019-dirty

Hi,

On Tue, 14 Mar 2006, Qingning Huo wrote:

-	var=`git repo-config --get pull.octopus`
+	var=`git-repo-config --get pull.octopus`

This is unlikely to be applied; there are plans to have a "libexec" path 
in which all git executables are stored, and just the "git" wrapper in the 
path. Your patch would break git in those setups.

Ciao,
Dscho

P.S.: BTW there are quite a few discussions of this in the mailing list 
archives...

On Tue, Mar 14, 2006 at 10:20:53PM +0100, Johannes Schindelin wrote:

Hi,

On Tue, 14 Mar 2006, Qingning Huo wrote:

quoted

-	var=`git repo-config --get pull.octopus`
+	var=`git-repo-config --get pull.octopus`

This is unlikely to be applied; there are plans to have a "libexec" path 
in which all git executables are stored, and just the "git" wrapper in the 
path. Your patch would break git in those setups.

I do not mind whether this patch is applied.  What I want is git calls
its helper programs, instead of any random git program in my PATH.  If
git-programs are installed to libexec path, how about calling them
with absolute path?

Regards,
Qingning

On Tue, 14 Mar 2006, Qingning Huo wrote:

The system have GNU git installed at /usr/bin/git.  I installed git-core
to ~/opt/bin.  ~/opt/bin is in my PATH, but is after /usr/bin.  I have
set alias git="$HOME/opt/bin/git".

This should not be a problem with the modern "git.c" wrapper. It 
_should_, if you call it with the full path, automatically prepend that 
path to the PATH when executing sub-commands. 

So if you run git as "$HOME/opt/bin/git", the PATH _should_ be 
 - first the "PREFIX/bin" path as defined by the build
 - second the "$HOME/opt/bin/" path as defined by the fact that you ran 
   git from that path
 - finally the normal $PATH.

To check this out, do this:

	ln -s /usr/bin/printenv ~/opt/bin/git-printenv
	git printenv

and you should see the proper PATH that git ends up using internally that 
way.

So your problem seems to be that you do "git-pull", when you really should 
do "git pull" (where that wrapper will set up PATH for you). Since you 
don't use the wrapper, the scripts end up doing the wrong thing.

		Linus

On Tue, Mar 14, 2006 at 01:58:09PM -0800, Linus Torvalds wrote:

On Tue, 14 Mar 2006, Qingning Huo wrote:

quoted

The system have GNU git installed at /usr/bin/git.  I installed git-core
to ~/opt/bin.  ~/opt/bin is in my PATH, but is after /usr/bin.  I have
set alias git="$HOME/opt/bin/git".

This should not be a problem with the modern "git.c" wrapper. It 
_should_, if you call it with the full path, automatically prepend that 
path to the PATH when executing sub-commands. 

So if you run git as "$HOME/opt/bin/git", the PATH _should_ be 
 - first the "PREFIX/bin" path as defined by the build
 - second the "$HOME/opt/bin/" path as defined by the fact that you ran 
   git from that path
 - finally the normal $PATH.

To check this out, do this:

	ln -s /usr/bin/printenv ~/opt/bin/git-printenv
	git printenv

and you should see the proper PATH that git ends up using internally that 
way.

So your problem seems to be that you do "git-pull", when you really should 
do "git pull" (where that wrapper will set up PATH for you). Since you 
don't use the wrapper, the scripts end up doing the wrong thing.

Thanks for your detailed explanation.  Yes, "git push" and "git pull"
both work fine out of the box.  That is the good thing.  But,

$ grep git git-pull.sh

. git-sh-setup
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
git-fetch --update-head-ok "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD)
        git-read-tree -u -m "$orig_head" "$curr_head" ||
        var=`git repo-config --get pull.octopus`
        var=`git repo-config --get pull.twohead`
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head

We have "git-read-tree" and "git repo-config" at the same time.  Are
there any rules saying which form should be preferred?  How about pick
one form and stick to it?

If we uniformly call git helper programs/scripts with "git helper"
style, would git(1) append two paths to PATH everytime it is being
invoked?  For example, "git pull" -> "git repo-config" would prepend
~/opt/bin four times to PATH.  This wouldn't be very effecient.

Regards,
Qingning

On Tue, 14 Mar 2006, Qingning Huo wrote:

Thanks for your detailed explanation.  Yes, "git push" and "git pull"
both work fine out of the box.  That is the good thing.  But,

$ grep git git-pull.sh

. git-sh-setup
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
git-fetch --update-head-ok "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD)
        git-read-tree -u -m "$orig_head" "$curr_head" ||
        var=`git repo-config --get pull.octopus`
        var=`git repo-config --get pull.twohead`
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head

We have "git-read-tree" and "git repo-config" at the same time.  Are
there any rules saying which form should be preferred?  How about pick
one form and stick to it?

I agree that it is inconsistent as-is. So a patch to make it use the 
"git-repo-config" form (the argument being that internally, we use the 
full names) might be good if just for consistency.

		Linus

On Tue, Mar 14, 2006 at 03:07:39PM -0800, Linus Torvalds wrote:

On Tue, 14 Mar 2006, Qingning Huo wrote:

quoted

We have "git-read-tree" and "git repo-config" at the same time.  Are
there any rules saying which form should be preferred?  How about pick
one form and stick to it?

I agree that it is inconsistent as-is. So a patch to make it use the 
"git-repo-config" form (the argument being that internally, we use the 
full names) might be good if just for consistency.

Can these two patches be accepted then?  What do others think?

Qingning