From: Johannes Sixt <j.sixt@viscovery.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] help git-upload-pack find git
Date: Tue, 16 Sep 2008 08:17:14 +0200 [thread overview]
Message-ID: <48CF4F6A.6080604@viscovery.net> (raw)
In-Reply-To: <48CEC3FB.5070101@drmicha.warpmail.net>
Michael J Gruber schrieb:
> I was actually surprised that setup_path() uses argv0_path without
> setting it, same as with argv_exec_path. I assumed this is for a good
> reason, I'm lacking the code base overview to judge this myself.
It argv_exec_path comes from git --exec-path=..., hence, git (via git.c)
is the only caller of setup_path() that is able to set it. We can leave
that one out of the equation.
> In any case, git.c sets argv0_path early, messes a bit with argv[0] and
> calls setup_path afterwards anyways. So adding the path in setup_path()
> should not hurt any "git foo" command.
>
> One could construe situations where even that wouldn't help, because
> git-upload-pack can't pass --exec-dir to git and they can be in
> different locations - but I think that's crazy.
>
> git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.
> setup_path() needs to get a parameter. If shell.c should profit from the
> change then it needs to be taught how to pass an absolute path to
> do_{generic,cvs}_cmd().
>
> So, I guess the general approach (change setup() path and have every
> caller profit) is OK. OK with you?
Have you studied the commit message of e1464ca7bb0d (Record the command
invocation path early) and the context in which this commit occurs? It's
about relocatable git installations and how system_path() derives various
other paths from argv[0].
Please show how you think you could change setup_path(), but keep in mind
that in git.c you neither can do the equivalent of git_set_argv0_path()
later nor setup_path() earlier.
-- Hannes
next prev parent reply other threads:[~2008-09-16 6:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 2:29 git-clone: path or ssh problem with git-upload-pack in 1.6.0? Paul Johnston
2008-09-15 8:30 ` Paul Johnston
2008-09-15 16:24 ` [PATCH] help git-upload-pack find git Michael J Gruber
2008-09-15 19:34 ` Junio C Hamano
2008-09-15 20:22 ` Michael J Gruber
2008-09-16 6:17 ` Johannes Sixt [this message]
2008-09-16 13:15 ` Michael J Gruber
2008-09-16 13:43 ` Johannes Sixt
2008-09-16 15:38 ` Michael J Gruber
2008-09-15 16:25 ` git-clone: path or ssh problem with git-upload-pack in 1.6.0? Michael J Gruber
2008-09-15 22:39 ` Michael Wookey
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=48CF4F6A.6080604@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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;
as well as URLs for NNTP newsgroup(s).