From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:21
Qingning Huo [off-list ref] writes:
So we recognize the full path approach is desired,
I said "if you can work problems your environment has _without_
doing the full path thing, then it would be ideal".
I never said full path is desired -- I despise full path, in
fact. It makes certain things very inconvenient.
...but because of
technique reasons (building and testing), it is not applied.
There were not even a patch. I suspect people involved in the
discussion realized that approach was unworkably cumbersome.
In our Makefile, we have sed script mechanism to replace tokens
so we _could_ change our sources to do something like this:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..10835c6 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ @@GIT_PATH@@git-ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ @@GIT_PATH@@git-diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
and sed it out with 's/@@GIT_PATH@@/$(gitexecdir_SQ)/g'.
However, you have to realize that I often want to try things out
*without* running "make", let alone installing. The current way
things are set up lets me say:
$ GIT_EXEC_PATH=$my_git_source \
sh -x $my_git_source/git-commit.sh
to see where things break. Changing things the way I quoted
above would make things _extremely_ inconvenient for me.
And it is ugly. "Making things ugly and inconvenient for what
purpose?" is the question I have to ask myself at this point.
And if the answer is "to support unusual configuration which,
quite frankly, I think is broken", then...
We could probably define a shell function that looks like:
git_exec () {
cmd="$1"
shift
case "${GIT_EXEC_PATH+set}" in
set) ;;
*) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;
esac
"$GIT_EXEC_PATH/git-$cmd" "$@"
}
in git-sh-setup [*1*], and then rewrite the above to something
like this instead:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..8a73420 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ git_exec ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ git_exec diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
But that does not cover Perl nor Python scripts, and does not
address the ugliness either.
[Footnote]
*1* BTW, I just noticed that git-sh-setup needs to be on user's
PATH, so we probably have to inline and duplicate the git_exec()
shell function definition at the beginning of each script after
all, when we make the initial ". git-sh-setup" inclusion to
honor GIT_EXEC_PATH without munging the user's PATH.
Which is not a big deal by itself, since we preprocess
*.{sh,perl,py} files anyway, but still it leaves a _big_
ugliness factor.
From: Mark Wooding <hidden> Date: 2016-06-15 22:42:21
Junio C Hamano [off-list ref] wrote:
*1* BTW, I just noticed that git-sh-setup needs to be on user's
PATH, so we probably have to inline and duplicate the git_exec()
shell function definition at the beginning of each script after
all, when we make the initial ". git-sh-setup" inclusion to
honor GIT_EXEC_PATH without munging the user's PATH.
. ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
isn't too grim, and shows how the git_exec shell function can be made
somewhat terser.
By the way, am I the only person who /likes/ having all the git-*
programs on his path? It makes shell completion work fairly well
without having to install strange completion scripts which get out of
date for one thing.
-- [mdw]
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
Mark Wooding wrote:
Junio C Hamano [off-list ref] wrote:
quoted
*1* BTW, I just noticed that git-sh-setup needs to be on user's
PATH, so we probably have to inline and duplicate the git_exec()
shell function definition at the beginning of each script after
all, when we make the initial ". git-sh-setup" inclusion to
honor GIT_EXEC_PATH without munging the user's PATH.
. ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
isn't too grim, and shows how the git_exec shell function can be made
somewhat terser.
But it breaks the convenience when testing.
By the way, am I the only person who /likes/ having all the git-*
programs on his path? It makes shell completion work fairly well
without having to install strange completion scripts which get out of
date for one thing.
I like it too, but I don't use it unless I can't remember what the
command was named (finger-training). It shouldn't be too difficult to
make git.c write its own auto-generated bash-completion rules. If
someone would care to teach me the syntax I'd gladly hack up a patch for
it. This is a Good Thing, since it means it would also work for the
internal commands, which bash's path-completion doesn't.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Timo Hirvonen <hidden> Date: 2016-06-15 22:42:21
On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
Mark Wooding [off-list ref] wrote:
By the way, am I the only person who /likes/ having all the git-*
programs on his path? It makes shell completion work fairly well
without having to install strange completion scripts which get out of
date for one thing.
I like git-* for the same reason. But if git potty had aliases for long
commands then git-* commands would become irrelevant. Especially
"git co" would be nice. It even would be faster to type than
git-ch<tab>c<tab>o<tab> ;)
--
http://onion.dynserv.net/~timo/
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
Timo Hirvonen wrote:
On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
Mark Wooding [off-list ref] wrote:
quoted
By the way, am I the only person who /likes/ having all the git-*
programs on his path? It makes shell completion work fairly well
without having to install strange completion scripts which get out of
date for one thing.
I like git-* for the same reason. But if git potty had aliases for long
commands then git-* commands would become irrelevant. Especially
"git co" would be nice. It even would be faster to type than
git-ch<tab>c<tab>o<tab> ;)
It would indeed, and it should also be fairly trivial. However, adding
short-hands that are identical with cvs and svn but does a totally
different thing (well, not really different, but cvs users will be
surprised) is not necessarily a good thing.
It would be better, imo, to add ambiguity detection for commands that
lacks an exact match. That way "git br" and "git branch" would be
identical and the logic only needs doing once. I'm not terribly excited
about it though, so...
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Qingning Huo <hidden> Date: 2016-06-15 22:42:21
On Thu, Mar 16, 2006 at 12:26:09AM -0800, Junio C Hamano wrote:
We could probably define a shell function that looks like:
git_exec () {
cmd="$1"
shift
case "${GIT_EXEC_PATH+set}" in
set) ;;
*) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;
esac
"$GIT_EXEC_PATH/git-$cmd" "$@"
}
in git-sh-setup [*1*], and then rewrite the above to something
like this instead:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..8a73420 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ git_exec ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ git_exec diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
But that does not cover Perl nor Python scripts, and does not
address the ugliness either.
This is similiar to what I had in mind when I recommended the full path
approach. Perl or Python should be able to do the similiar. I have no
comment on the ugliness. The functionality and effeciency of the
program is more important to me. But I do recognize the difficulties of
changing all scripts overnight.
Anyway, there are at least other two ways to solve my problem. (a)
setup PATH in git-sh-setup, or (b) consistently use git-command form in
scripts. Even before their implementation, I can still use "git push".
Qingning
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:21
Andreas Ericsson [off-list ref] writes:
quoted
. ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
isn't too grim, and shows how the git_exec shell function can be made
somewhat terser.
But it breaks the convenience when testing.
I think that's OK. When I test things in the build directory
without installing I would usually do:
$ GIT_EXEC_PATH=`pwd` PATH=`pwd`:/usr/bin:/bin ./git-cmd-to-test
and the above would not break things.