Git development
 help / color / mirror / Atom feed
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 00:26:09 -0800	[thread overview]
Message-ID: <7v64mebxsu.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:

> 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.

  parent reply	other threads:[~2006-03-16  8:26 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 [this message]
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
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=7v64mebxsu.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