Re: [PATCH 3/6] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 10, 2009, 14:34 UTC
- Message-ID
- <alpine.DEB.1.00.0901101532430.30769@pacific.mpi-cbg.de>
- In-Reply-To
- <1231595452-27698-3-git-send-email-prohaska@zib.de>
Hi,
On Sat, 10 Jan 2009, Steffen Prohaska wrote:
Show 17 quoted lines
> From: Steve Haslam <shaslam@lastminute.com> > > If the user specified the full path to git-upload-pack as the -u option to > "git clone" when cloning a remote repository, and git was not on the default > PATH on the remote machine, git-upload-pack was failing to exec > git-pack-objects. > > By making the argv[0] path (if any) available to setup_path(), this will > allow finding the "git" executable in the same directory as > "git-upload-pack". The default built in to exec_cmd.c is to look for "git" > in the ".../libexec/git-core" directory, but it is not installed there (any > longer). > > Much the same applies to invoking git-receive-pack from a non-PATH location > using the "--exec" argument to "git push". > > [ spr: split Steve's original commit into two commits. ]
I think you do not want to have that [ ... ] in the commit message, but after the "--".
Further, it would make sense to have these 2 patches independently, provided that a test is added with which we could verify that the patches are actually necessary for upload-pack/receive-pack.
Logically, and to avoid committing a broken revision, 1/6 should come last, methinks.
Ciao, Dscho