Re: [PATCH] (Updated) Exec git programs without using PATH.

From: Junio C Hamano <junkio@cox.net>
Date: Jan 11, 2006, 20:33 UTC
Message-ID: <7vek3esdw0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1136999157.11717.658.camel@brick.watson.ibm.com>

Michal Ostrowski <mostrows@watson.ibm.com> writes:

> The git suite may not be in PATH (and thus programs such as
>...
> Includes modifications by Junio C Hamano <junkio@cox.net>.

Thanks for the update (you did it even without line wrapping this time).

I made further fixes last night and it is in the proposed updates ("pu") branch. This branch is used to hold and showcase what I plan to eventually merge into the master branch, and consists of the topic branches merged on top of what is in the master branch. To disect to see what shape I munged your patch into, please look at it with gitk or gitweb and find "Merge branch mo/exec" commit (my topic branches are named after patch author and topic keyword). The second parent of that commit is the tip of the topic branch mo/exec when the merge was made.

A word of caution to people on the list (not limited to Michal) is needed again, because it's been a while since I talked about the proposed updates branch last time (which was pre 1.0.0 release IIRC).

The "pu" branch is regularly rebuilt by merging private topic branches on top of the then-current master branch, by doing this:

	$ git checkout pu
        $ git reset --hard master ;# build from scratch!
        $ git pull . topic1
        $ git pull . topic2
        $ ...
        $ git pull . topicN

What this means is that you (not just Michal---"people") should not base your development on top of "pu" branch proper, since you will have a hard time updating and merging. Disecting my "pu" branch to find the topic branch that corresponds to your topic, and doing your development and patch preparation based on that branch tip (and tell me that the patch is against your topic branch, or "pu") is possible, but even that is not always an easy option, since I may occasionally have to rebase my topic branches as well. You can always send in an updated patch based on my master, and I'll manage with three-way merge to pick out the real changes since your last iteration.

For your (primarily Michal, but other interested parties as well) reference, here is the diff between your patch in the message I am replying to and what I placed in the "pu" branch last night.

-- >8 -- Updates on top of comments last night.

 - git-unpack-objects are run via execv_git_cmd, so no "git-"
   prefix should be given.

 - two more files need #include "exec_cmd.h".

---

diff --git a/receive-pack.c b/receive-pack.c
index 6120dbe..eae31e3 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -6,7 +6,7 @@
 
 static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
 
-static char *unpacker[] = { "git-unpack-objects", NULL };
+static char *unpacker[] = { "unpack-objects", NULL };
 
 static int report_status = 0;
 
diff --git a/send-pack.c b/send-pack.c
index 4a420a6..990be3f 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -3,6 +3,7 @@
 #include "tag.h"
 #include "refs.h"
 #include "pkt-line.h"
+#include "exec_cmd.h"
 
 static const char send_pack_usage[] =
 "git-send-pack [--all] [--exec=git-receive-pack] <remote> [<head>...]\n"
diff --git a/shell.c b/shell.c
index d40dfe4..fc0c73c 100644
--- a/shell.c
+++ b/shell.c
@@ -1,5 +1,6 @@
 #include "cache.h"
 #include "quote.h"
+#include "exec_cmd.h"
 
 static int do_generic_cmd(const char *me, char *arg)
 {