* Re: Proxy and authentication
From: Nick Hengeveld @ 2006-01-11 18:51 UTC (permalink / raw)
To: Beber; +Cc: git
In-Reply-To: <4615f4910601110653k5e2e8ffapb962a8b0829eeb11@mail.gmail.com>
On Wed, Jan 11, 2006 at 03:53:23PM +0100, Beber wrote:
> Is there plan to allow proxy authentication and http/webdav remote
> repository authentication ?
You can use .netrc for HTTP auth credentials, but I don't believe that
handles proxy authentication.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* reverting back both working copy and commits
From: Bahadir Balban @ 2006-01-11 16:32 UTC (permalink / raw)
To: git
Hi,
I made some commits that later on I wanted to cancel. I did:
% git-branch master-2006-get-rid-of-commits
% git-reset --hard [sha1id]
where sha1id is the id of commit I want to revert back to. After this,
git-log points at the right commit (the one with [sha1id]) as the last
commit made. However, the working copy is left in the original state,
i.e with the unwanted changes.. How do I also revert the working
sources into an earlier state.
Because git-commit says "nothing to change" at this stage, git
checkout -f does not cure my problem. How do I also revert working
copy to earlier commit?
Thanks,
Bahadir
^ permalink raw reply
* Re: Proxy and authentication
From: Martin Langhoff @ 2006-01-11 18:26 UTC (permalink / raw)
To: Beber; +Cc: git
In-Reply-To: <4615f4910601110653k5e2e8ffapb962a8b0829eeb11@mail.gmail.com>
On 1/12/06, Beber <beber.lkml@gmail.com> wrote:
> Is there plan to allow proxy authentication and http/webdav remote
> repository authentication ?
> It seem that's it's quiet non-working for now.
search the list archives for more detail, but
export http_proxy=http://my.proxy.tld:8080/
git foo
should work. Have you tried embedding auth details in the url? Try
http://user:pass@my.proxy.tld:8080/
cheers,
martin
^ permalink raw reply
* git binary size...
From: Linus Torvalds @ 2006-01-11 18:26 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Guess what the difference is here?
[torvalds@g5 ~]$ du -sh bin/
14M bin/
[torvalds@g5 ~]$ du -sh bin/
5.8M bin/
Give up?
In one case, "git" was compiled with the default options in the git
Makefile. In the other one, the "-g" was removed.
Now, maybe this is extra visible with PowerPC (32-bit) binaries, and it's
not as bad on x86, but it's still a bit distressing.
That "-g" doesn't buy users much of anything, and I doubt most developers
care that deeply most of the time either (and can easily add it when they
do care). It's left-over from long ago when it was much more useful.
So I'd suggest just removing it.
Linus
^ permalink raw reply
* Re: git-bisect is magical
From: walt @ 2006-01-11 18:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601101846170.3294@g5.osdl.org>
Linus Torvalds wrote:
[...]
> So when you did "git checkout origin", you basically blew away all the
> development you had done in the default "master" branch, and switched to
> _another_ branch...
First, many thanks to you, Junio, and Sean (by email) for the great
replies -- all three were extremely helpful, and this is all finally
starting to make sense to me.
Now, I don't know whether this anecdote will give you any new
information, but I'll offer it.
After I did the 'git checkout origin' yesterday, I didn't (yet) know
what I was doing, so I made the following pilot-errors while still
in 'origin': I did 'git-reset --hard origin' and then very early
this morning I did cg-update, both of which seemed to work fine and
gave no error messages, and I compiled a new kernel from the result.
After reading the three essays from you guys :o) I realized that I
had made these two mistakes, and tried to switch back to master:
$git-branch
bisect
master
* origin
$git-checkout master
fatal: Entry 'Documentation/kernel-parameters.txt' would be overwritten
by merge. Cannot merge.
So I cloned a fresh copy of your repository and built a new kernel.
What I learned from this was that the new fixes to Makefile and
setlocalversion (at a minimum) were not actually applied to the
checked-out sources in my 'origin' misadventure. (I watched the
commits being listed by cg-update, so I know the fixes were really
downloaded -- but they were not applied to the checked-out sources
as they normally would be.)
Would these anomalous results be expected -- given the, um, unusual
circumstances?
Thanks again!
^ permalink raw reply
* Re: RFC: Subprojects
From: Linus Torvalds @ 2006-01-11 17:42 UTC (permalink / raw)
To: Simon Richter; +Cc: Johannes Schindelin, git
In-Reply-To: <43C537C9.4090206@hogyros.de>
On Wed, 11 Jan 2006, Simon Richter wrote:
>
> The important thing for me is that I need to be able to transfer them easily,
> or turn a subdirectory into a subproject or vice versa.
Turning a _snapshot_ of a subproject into a subdirectory is easy: you can
literally just create a subdirectory, copy it there, and it will re-use
all the objects that the subproject uses (ie the top-level project will
have a "tree" entry that just points to the same tree entry as the
top-level commit in the sub-project).
However, while that works as a way to import snapshots, it doesn't work in
any other way. It allows you to share objects with the "real project", and
it's space-efficient etc, but there's no shared history, and you cannot
merge back-and-forth, which is probably what you really want to do.
Quite frankly, you really probably want more of a "git-aware symlink" kind
of thing. I'd really hesitate (in fact, I'd object) to re-use the existing
"tree" type for it, but you're not the only one to have asked for
subproject support, so this is clearly not a odd request.
> > Sorry, we discussed similar things already. It is not necessary to change
> > the structure. Even more: it makes no sense. Why would you want to have two
> > or more commit messages for the same revision?
>
> Because the commit affects both the subproject and the master project.
What we _could_ do is for you to first do a commit in the "independent"
subproject (it really would be a totally independent git repository in all
ways: you could continue to merge it with other subprojects of the same
type), and then you could commit a new pointer to that subproject in the
master project.
The two would really be fundamentally independent: they'd be two different
git projects, one would just have a strange kind of "symlink" to the
other, which would include a name and the top commit SHA1 of the other
project.
Getting everything to work reasonably seamlessly would be potentially
painful (getting "git diff" to recurse into the subdirectory correctly is
non-trivial: you'd have a separate ".git/index" file for it), but it
sounds doable.
I'd suggest adding a new kind of object ("gitlink") which has some
well-specified format (20-byte SHA1 + ASCII C string "name" - the name
translation to external repository would be done in the .git/config file
of the "outer" project). Then a special file mode to indicate that in the
"struct tree", and support for "git-update-cache" to understand how such
an object is really tied into the "<pathname>/.git/HEAD" file rather than
the rest of the directory contents.
Then a "git fetch" would have to be taught to recursively fetch the other
subproject when the "gitlink" changes.
It should be doable: somebody could try to implement a rough first draft
(maybe not very seamless at first).
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Jon Loeliger @ 2006-01-11 17:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Git List
In-Reply-To: <43C4F292.7010404@op5.se>
On Wed, 2006-01-11 at 05:57, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> >
> > True, but *please* stop calling "git wrapper" a potty. It gives
> > me an impression that it is not connected to the plumbing.
> >
>
> Aww... And here I was being quite pleased with this wording in the man-page:
>
> "The program git is just a wrapper to reach the core git programs (or a
> potty if you like, as it's not exactly porcelain but still brings your
> stuff to the plumbing)."
Oh man. So, do we have to go with "kitchen sink" instead? ;-)
jdl
^ permalink raw reply
* [PATCH] (Updated) Exec git programs without using PATH.
From: Michal Ostrowski @ 2006-01-11 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7v4q4bwavi.fsf@assigned-by-dhcp.cox.net>
The git suite may not be in PATH (and thus programs such as
git-send-pack could not exec git-rev-list). Thus there is a need for
logic that will locate these programs. Modifying PATH is not
desirable as it result in behavior differing from the user's
intentions, as we may end up prepending "/usr/bin" to PATH.
- git C programs will use exec*_git_cmd() APIs to exec sub-commands.
- exec*_git_cmd() will execute a git program by searching for it in
the following directories:
1. --exec-path (as used by "git")
2. The GIT_EXEC_PATH environment variable.
3. $(gitexecdir) as set in Makefile (default value $(bindir)).
- all exec's of git programs will use exec*_git_cmd() interfaces,
- C programs will not modify PATH
If the git suite is not in PATH, C programs will function, but there
is no guarantee that shell scripts will, as shell scripts may invoke
"git-foo" rather than "git foo". Shell scripts that are modified to
use the git potty should become independent of PATH.
Includes modifications by Junio C Hamano <junkio@cox.net>.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
Makefile | 13 ++++--
daemon.c | 3 +
exec_cmd.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
exec_cmd.h | 10 +++++
fetch-clone.c | 7 +--
git.c | 50 +++++-------------------
receive-pack.c | 4 +-
run-command.c | 9 +++-
run-command.h | 2 -
send-pack.c | 8 ++--
shell.c | 6 ++-
upload-pack.c | 7 ++-
12 files changed, 174 insertions(+), 62 deletions(-)
create mode 100644 exec_cmd.c
create mode 100644 exec_cmd.h
565e290d6e7f24bd4e72ca7494297230799d118a
diff --git a/Makefile b/Makefile
index c9c15b5..abcb771 100644
--- a/Makefile
+++ b/Makefile
@@ -68,6 +68,7 @@ ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
+gitexecdir = $(prefix)/bin
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -141,7 +142,7 @@ PROGRAMS = \
git-describe$X
# what 'all' will build and 'install' will install.
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -173,7 +174,7 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o count-delta.o csum-file.o \
- date.o diff-delta.o entry.o ident.o index.o \
+ date.o diff-delta.o entry.o exec_cmd.o ident.o index.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
@@ -366,13 +367,13 @@ LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS)
+all: $(ALL_PROGRAMS) git$X
all:
$(MAKE) -C templates
git$X: git.c $(LIB_FILE)
- $(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
+ $(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -412,6 +413,8 @@ git$X git.spec \
%.o: %.S
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
+exec_cmd.o: ALL_CFLAGS += -DGIT_EXEC_PATH=\"$(gitexecdir)\"
+
git-%$X: %.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
@@ -468,7 +471,9 @@ check:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
$(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) git$X $(call shellquote,$(DESTDIR)$(gitexecdir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
diff --git a/daemon.c b/daemon.c
index 3bd1426..bb014fa 100644
--- a/daemon.c
+++ b/daemon.c
@@ -9,6 +9,7 @@
#include <syslog.h>
#include "pkt-line.h"
#include "cache.h"
+#include "exec_cmd.h"
static int log_syslog;
static int verbose;
@@ -227,7 +228,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf, ".", NULL);
+ execl_git_cmd("upload-pack", "--strict", timeout_buf, ".", NULL);
return -1;
}
diff --git a/exec_cmd.c b/exec_cmd.c
new file mode 100644
index 0000000..55af33b
--- /dev/null
+++ b/exec_cmd.c
@@ -0,0 +1,117 @@
+#include "cache.h"
+#include "exec_cmd.h"
+#define MAX_ARGS 32
+
+extern char **environ;
+static const char *builtin_exec_path = GIT_EXEC_PATH;
+static const char *current_exec_path = NULL;
+
+void git_set_exec_path(const char *exec_path)
+{
+ current_exec_path = exec_path;
+}
+
+
+/* Returns the highest-priority, location to look for git programs. */
+const char *git_exec_path()
+{
+ const char *env;
+
+ if (current_exec_path)
+ return current_exec_path;
+
+ env = getenv("GIT_EXEC_PATH");
+ if (env) {
+ return env;
+ }
+
+ return builtin_exec_path;
+}
+
+
+int execv_git_cmd(char **argv)
+{
+ char git_command[PATH_MAX + 1];
+ char *tmp;
+ int len, err, i;
+ const char *paths[] = { current_exec_path,
+ getenv("GIT_EXEC_PATH"),
+ builtin_exec_path };
+
+ for (i = 0; i < sizeof(paths)/sizeof(paths[0]); ++i) {
+ const char *exec_dir = paths[i];
+ if (!exec_dir) continue;
+
+ if (*exec_dir != '/') {
+ if (!getcwd(git_command, sizeof(git_command))) {
+ fprintf(stderr, "git: cannot determine "
+ "current directory\n");
+ exit(1);
+ }
+ len = strlen(git_command);
+
+ /* Trivial cleanup */
+ while (!strncmp(exec_dir, "./", 2)) {
+ exec_dir += 2;
+ while (*exec_dir == '/')
+ exec_dir++;
+ }
+ snprintf(git_command + len, sizeof(git_command) - len,
+ "/%s", exec_dir);
+ } else {
+ strcpy(git_command, exec_dir);
+ }
+
+ len = strlen(git_command);
+ len += snprintf(git_command + len, sizeof(git_command) - len,
+ "/git-%s", argv[0]);
+
+ if (sizeof(git_command) <= len) {
+ fprintf(stderr,
+ "git: command name given is too long.\n");
+ break;
+ }
+
+ /* argv[0] must be the git command, but the argv array
+ * belongs to the caller, and my be reused in
+ * subsequent loop iterations. Save argv[0] and
+ * restore it on error.
+ */
+
+ tmp = argv[0];
+ argv[0] = git_command;
+
+ /* execve() can only ever return if it fails */
+ execve(git_command, argv, environ);
+
+ err = errno;
+
+ argv[0] = tmp;
+ }
+ return -1;
+
+}
+
+
+int execl_git_cmd(char *cmd,...)
+{
+ int argc;
+ char *argv[MAX_ARGS + 1];
+ char *arg;
+ va_list param;
+
+ va_start(param, cmd);
+ argv[0] = cmd;
+ argc = 1;
+ while (argc < MAX_ARGS) {
+ arg = argv[argc++] = va_arg(param, char *);
+ if (!arg)
+ break;
+ }
+ va_end(param);
+ if (MAX_ARGS <= argc)
+ return error("too many args to run %s", cmd);
+
+ argv[argc] = NULL;
+ return execv_git_cmd(argv);
+}
diff --git a/exec_cmd.h b/exec_cmd.h
new file mode 100644
index 0000000..5150ee2
--- /dev/null
+++ b/exec_cmd.h
@@ -0,0 +1,10 @@
+#ifndef __GIT_EXEC_CMD_H_
+#define __GIT_EXEC_CMD_H_
+
+extern void git_set_exec_path(const char *exec_path);
+extern const char* git_exec_path(void);
+extern int execv_git_cmd(char **argv); /* NULL terminated */
+extern int execl_git_cmd(char *cmd, ...);
+
+
+#endif /* __GIT_EXEC_CMD_H_ */
diff --git a/fetch-clone.c b/fetch-clone.c
index f46fe6e..859f400 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
#include <sys/wait.h>
static int finish_pack(const char *pack_tmp_name, const char *me)
@@ -27,8 +28,7 @@ static int finish_pack(const char *pack_
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- execlp("git-index-pack","git-index-pack",
- "-o", idx, pack_tmp_name, NULL);
+ execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, NULL);
error("cannot exec git-index-pack <%s> <%s>",
idx, pack_tmp_name);
exit(1);
@@ -105,8 +105,7 @@ int receive_unpack_pack(int fd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-unpack-objects", "git-unpack-objects",
- quiet ? "-q" : NULL, NULL);
+ execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
die("git-unpack-objects exec failed");
}
close(fd[0]);
diff --git a/git.c b/git.c
index 5e7da74..4616df6 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@
#include <stdarg.h>
#include <sys/ioctl.h>
#include "git-compat-util.h"
+#include "exec_cmd.h"
#ifndef PATH_MAX
# define PATH_MAX 4096
@@ -233,14 +234,11 @@ int main(int argc, char **argv, char **e
{
char git_command[PATH_MAX + 1];
char wd[PATH_MAX + 1];
- int i, len, show_help = 0;
- char *exec_path = getenv("GIT_EXEC_PATH");
+ int i, show_help = 0;
+ const char *exec_path;
getcwd(wd, PATH_MAX);
- if (!exec_path)
- exec_path = GIT_EXEC_PATH;
-
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -256,10 +254,11 @@ int main(int argc, char **argv, char **e
if (!strncmp(arg, "exec-path", 9)) {
arg += 9;
- if (*arg == '=')
+ if (*arg == '=') {
exec_path = arg + 1;
- else {
- puts(exec_path);
+ git_set_exec_path(exec_path);
+ } else {
+ puts(git_exec_path());
exit(0);
}
}
@@ -275,42 +274,15 @@ int main(int argc, char **argv, char **e
if (i >= argc || show_help) {
if (i >= argc)
- cmd_usage(exec_path, NULL);
+ cmd_usage(git_exec_path(), NULL);
show_man_page(argv[i]);
}
- if (*exec_path != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr,
- "git: cannot determine current directory\n");
- exit(1);
- }
- len = strlen(git_command);
-
- /* Trivial cleanup */
- while (!strncmp(exec_path, "./", 2)) {
- exec_path += 2;
- while (*exec_path == '/')
- exec_path++;
- }
- snprintf(git_command + len, sizeof(git_command) - len,
- "/%s", exec_path);
- }
- else
- strcpy(git_command, exec_path);
- len = strlen(git_command);
- prepend_to_path(git_command, len);
-
- len += snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[i]);
- if (sizeof(git_command) <= len) {
- fprintf(stderr, "git: command name given is too long.\n");
- exit(1);
- }
+ exec_path = git_exec_path();
+ prepend_to_path(exec_path, strlen(exec_path));
- /* execve() can only ever return if it fails */
- execve(git_command, &argv[i], envp);
+ execv_git_cmd(argv + i);
if (errno == ENOENT)
cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
diff --git a/receive-pack.c b/receive-pack.c
index f847ec2..6120dbe 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 const char unpacker[] = "git-unpack-objects";
+static char *unpacker[] = { "git-unpack-objects", NULL };
static int report_status = 0;
@@ -257,7 +257,7 @@ static void read_head_info(void)
static const char *unpack(int *error_code)
{
- int code = run_command(unpacker, NULL);
+ int code = run_command_v_opt(1, unpacker, RUN_GIT_CMD);
*error_code = 0;
switch (code) {
diff --git a/run-command.c b/run-command.c
index 8bf5922..b3d287e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include <sys/wait.h>
+#include "exec_cmd.h"
int run_command_v_opt(int argc, char **argv, int flags)
{
@@ -13,9 +14,13 @@ int run_command_v_opt(int argc, char **a
int fd = open("/dev/null", O_RDWR);
dup2(fd, 0);
dup2(fd, 1);
- close(fd);
+ close(fd);
+ }
+ if (flags & RUN_GIT_CMD) {
+ execv_git_cmd(argv);
+ } else {
+ execvp(argv[0], (char *const*) argv);
}
- execvp(argv[0], (char *const*) argv);
die("exec %s failed.", argv[0]);
}
for (;;) {
diff --git a/run-command.h b/run-command.h
index 2469eea..ef3ee05 100644
--- a/run-command.h
+++ b/run-command.h
@@ -12,7 +12,7 @@ enum {
};
#define RUN_COMMAND_NO_STDIO 1
-
+#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
int run_command_v_opt(int argc, char **argv, int opt);
int run_command_v(int argc, char **argv);
int run_command(const char *cmd, ...);
diff --git a/send-pack.c b/send-pack.c
index cd36193..4a420a6 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -26,11 +26,11 @@ static int is_zero_sha1(const unsigned c
static void exec_pack_objects(void)
{
static char *args[] = {
- "git-pack-objects",
+ "pack-objects",
"--stdout",
NULL
};
- execvp("git-pack-objects", args);
+ execv_git_cmd(args);
die("git-pack-objects exec failed (%s)", strerror(errno));
}
@@ -39,7 +39,7 @@ static void exec_rev_list(struct ref *re
static char *args[1000];
int i = 0;
- args[i++] = "git-rev-list"; /* 0 */
+ args[i++] = "rev-list"; /* 0 */
args[i++] = "--objects"; /* 1 */
while (refs) {
char *buf = malloc(100);
@@ -58,7 +58,7 @@ static void exec_rev_list(struct ref *re
refs = refs->next;
}
args[i] = NULL;
- execvp("git-rev-list", args);
+ execv_git_cmd(args);
die("git-rev-list exec failed (%s)", strerror(errno));
}
diff --git a/shell.c b/shell.c
index cd31618..d40dfe4 100644
--- a/shell.c
+++ b/shell.c
@@ -7,12 +7,14 @@ static int do_generic_cmd(const char *me
if (!arg || !(arg = sq_dequote(arg)))
die("bad argument");
+ if (strncmp(me, "git-", 4))
+ die("bad command");
- my_argv[0] = me;
+ my_argv[0] = me + 4;
my_argv[1] = arg;
my_argv[2] = NULL;
- return execvp(me, (char**) my_argv);
+ return execv_git_cmd((char**) my_argv);
}
static struct commands {
diff --git a/upload-pack.c b/upload-pack.c
index 1834b6b..d198055 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -4,6 +4,7 @@
#include "tag.h"
#include "object.h"
#include "commit.h"
+#include "exec_cmd.h"
static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
@@ -60,7 +61,7 @@ static void create_pack_file(void)
close(0);
close(fd[0]);
close(fd[1]);
- *p++ = "git-rev-list";
+ *p++ = "rev-list";
*p++ = "--objects";
if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
@@ -79,13 +80,13 @@ static void create_pack_file(void)
buf += 41;
}
*p++ = NULL;
- execvp("git-rev-list", argv);
+ execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
}
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-pack-objects", "git-pack-objects", "--stdout", NULL);
+ execl_git_cmd("pack-objects", "--stdout", NULL);
die("git-upload-pack: unable to exec git-pack-objects");
}
--
0.99.9m-g5a22
^ permalink raw reply related
* Re: RFC: Subprojects
From: Simon Richter @ 2006-01-11 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601111740220.17966@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
Hello,
Johannes Schindelin wrote:
> And since the subprojects are really independent, you can connect them by
> an octopus.
The important thing for me is that I need to be able to transfer them
easily, or turn a subdirectory into a subproject or vice versa.
> Sorry, we discussed similar things already. It is not necessary to change
> the structure. Even more: it makes no sense. Why would you want to have
> two or more commit messages for the same revision?
Because the commit affects both the subproject and the master project.
> Remember: trees, commits and tags (objects in general) are immutable. You
> may think that you just commit a new revision of the subproject, and it is
> picked up by the overall project, but that is not the case!
This is why I asked for intended behaviour on commit in a subproject. It
is pretty obvious that the master project would need a new tree object
to reference the new version of the subproject, and hence, a new commit
to keep it all together (and correctly so, since I would like my master
project to refer to that particular version of the subproject that is
known to work).
> You can do this like I said: use branches (and possibly a common
> GIT_OBJECT_DIRECTORY to save on disk space).
Yes, however that wouldn't cover consistency between the subprojects,
would it?
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Checking git-cherry-pick Use Case
From: Jon Loeliger @ 2006-01-11 16:46 UTC (permalink / raw)
To: Git List
Guys,
Could you sanity check me on two issues with
my "work flow" here, please? Maybe I could do
something better/easier?
I have a repo with a bunch of commits coming from
several different places (me, co-worker, remote repo, etc).
I'm applying co-worker's patches into "cow" branch.
I'm applying my changes directly to "jdl" branch"
I'm pulling in "origin" crude.
Ultimately, I want to do development against the "sum total
set of all known patches supplied by anyone". Oh yeah.
So I make a "dev" branch that has "cow" + "jdl" + "origin".
However, at the end of the development day, I want to send
just _my_ patches upstream. Thus, I need to have my changes
sitting around neatly on the "jdl" branch.
I don't want to develop in the "jdl" branch, as it doesn't
have everything needed to test stuff properly (missing "cow"
code, eg.). So I actually edit and commit in the "dev"
branch where everything is unioned.
To isolate just my changes out of the "dev" branch into
the "jdl" branch, I cherry pick them like this:
$ git checkout dev
$ <do edit-compile-test cycle until all is well>
$ git commit -m "Stuff jdl made up and committed"
Now, things look, in part, like this:
! [dev] Stuff jdl made up and committed
* [jdl] Early stuff jdl made up
! [origin] Original stuff
---
+ [dev] Stuff jdl made up and committed
+ [dev^] Merge branch 'jdl'
++ [jdl] Early stuff jdl made up
+++ [origin] Original stuff
Then I pull that last "dev" commit over to "jdl":
$ git checkout jdl
$ git cherry-pick -r dev
Now it looks like this:
! [dev] Stuff jdl made up and committed
* [jdl] Early stuff jdl made up
! [origin] Original stuff
---
+ [jdl] Stuff jdl made up and committed
+ [dev] Stuff jdl made up and committed
+ [dev^] Merge branch 'jdl'
++ [jdl^] Early stuff jdl made up
+++ [origin] Original stuff
My first question is that I expected to see
something more like this (hand edited):
! [dev] Stuff jdl made up and committed
* [jdl] Early stuff jdl made up
! [origin] Original stuff
---
++ [dev] Stuff jdl made up and committed
+ [dev^] Merge branch 'jdl'
++ [jdl^] Early stuff jdl made up
+++ [origin] Original stuff
That is, the _same_ commit is now in both the "dev"
and "jdl" branches, so why does it have two lines here?
And finally, the "general" question: Is this a sane
work-flow used by anyone else? Or is there a different
perhaps even better way to do what I described above?
Thanks,
jdl
^ permalink raw reply
* Re: RFC: Subprojects
From: Johannes Schindelin @ 2006-01-11 16:44 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <43C52B1F.8020706@hogyros.de>
Hi,
On Wed, 11 Jan 2006, Simon Richter wrote:
> one thing that I have been missing so far in all SCM systems apart from CVS
> (and there it's just coincidence) is the ability to include a project as part
> of a bigger project. Developing software for embedded systems, I need that
> feature fairly often, for example the source tree for a particular device
> almost always contains one or more Linux trees, some binutils, gcc and gdb
> stuff and so on.
What I do: I call it a branch. While this might seem technically
incorrect, it is not.
And since the subprojects are really independent, you can connect them by
an octopus.
> The changes necessary here would be fairly simple: "tree" objects would point
> to a "commit" or a "tag" object when a subproject is used.
Sorry, we discussed similar things already. It is not necessary to change
the structure. Even more: it makes no sense. Why would you want to have
two or more commit messages for the same revision?
Remember: trees, commits and tags (objects in general) are immutable. You
may think that you just commit a new revision of the subproject, and it is
picked up by the overall project, but that is not the case!
> In the working directory, this would be represented by a .git directory that
> contains a symref to the embedding project instead of the objects directory.
> Head pointers are only required if you intend to push changes upstream to the
> maintainer of the embedded project. Each subproject has its own index.
You can do this like I said: use branches (and possibly a common
GIT_OBJECT_DIRECTORY to save on disk space).
Hth,
Dscho
^ permalink raw reply
* RFC: Subprojects
From: Simon Richter @ 2006-01-11 15:58 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
Hello,
one thing that I have been missing so far in all SCM systems apart from
CVS (and there it's just coincidence) is the ability to include a
project as part of a bigger project. Developing software for embedded
systems, I need that feature fairly often, for example the source tree
for a particular device almost always contains one or more Linux trees,
some binutils, gcc and gdb stuff and so on.
The changes necessary here would be fairly simple: "tree" objects would
point to a "commit" or a "tag" object when a subproject is used.
In the working directory, this would be represented by a .git directory
that contains a symref to the embedding project instead of the objects
directory. Head pointers are only required if you intend to push changes
upstream to the maintainer of the embedded project. Each subproject has
its own index.
Would such a feature make sense, and what behaviour would make the most
sense for the various operations (e.g. shall commits in the inner
project propagate to the outer?)?
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Proxy and authentication
From: Beber @ 2006-01-11 14:53 UTC (permalink / raw)
To: git
Hi,
Is there plan to allow proxy authentication and http/webdav remote
repository authentication ?
It seem that's it's quiet non-working for now.
Thanks
Beber
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Andreas Ericsson @ 2006-01-11 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xtn4m59.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> True, but *please* stop calling "git wrapper" a potty. It gives
> me an impression that it is not connected to the plumbing.
>
Aww... And here I was being quite pleased with this wording in the man-page:
"The program git is just a wrapper to reach the core git programs (or a
potty if you like, as it's not exactly porcelain but still brings your
stuff to the plumbing)."
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Gerrit Pape @ 2006-01-11 9:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqylpty1.fsf@assigned-by-dhcp.cox.net>
On Mon, Jan 09, 2006 at 02:38:30AM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > Coywolf Qi Hunt <qiyong@fc-cn.com> writes:
> >> Why not support debian? I see the debian directory is outdated.
> >
> > I think that was discussed already this year, so look in the
> > list archive for the past 10 days or so please before asking.
>
> Especially, please see this thread:
>
> http://marc.theaimsgroup.com/?l=git&m=113576889301331
>
> I haven't received any patches to re-add debian/ directory from
> Gerrit since I removed it, and I do not expect nor wish to get
> one. I respect Gerrit's request not to ship debian/ directory
> myself.
Thanks.
> If you want to see deb packages at kernel.org built by me, you
> need to convince both Gerrit and me with a workable workflow
> that does not add extra burden on us and avoids confusion.
I'm afraid, I can't always keep up with the git development speed. So
it's quite possible that a debian/ directory in the git repository gets
temporarily outdated and possibly broken, and I'm not available to
update immediately.
Starting with version 1.0.8-1, this should work if you want to build
Debian packages on sid or sarge from the maint or master branch (or the
v1.1.1 tag) yourself:
$ git checkout maint
$ wget -q -O- http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.0.8-1.diff.gz |
gunzip |patch -p1
patching file debian/changelog
patching file debian/control
patching file debian/copyright
patching file debian/rules
patching file debian/git-core.docs
patching file debian/git-doc.docs
patching file debian/implicit
patching file debian/git-core.postinst
patching file debian/git-core.prerm
$ chmod 755 debian/rules
$ debchange -v 1.1.1-0.maint20060111 'git maint 20060111'
$ dpkg-buildpackage -b -rfakeroot -uc -us
[...]
$
HTH, Gerrit.
^ permalink raw reply
* Re: Problem resolving an octopus merge conflict
From: Junio C Hamano @ 2006-01-11 8:33 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP1241F00474C3FC5C32F7A6AE240@CEZ.ICE>
"Sean" <seanlkml@sympatico.ca> writes:
> After fixing this up though, git-commit won't see this as a merge commit
> and won't add the proper parent linkages. I'm not sure at this point
> what the proper fix should be or if this is just pilot error.
Not a pilot error, and we do not make it explicit enough, but
git-merge-octopus has this comment:
echo "Simple merge did not work, trying automatic merge."
git-merge-index -o git-merge-one-file -a ||
exit 2 ; # Automatic merge failed; should not be doing Octopus
If you need to manually fix up such a merge, that is a sure sign
that the branches you merged into an Octopus was not independent
bunches after all. Letting such a commit to be made defeats the
point of an Octopus, which is to bundle independent tracks of
development.
This is more philosophical rather than technical, and may look
being unhelpful to you (who wanted to create an Octopus), but is
done to help people who later needs to deal with such a merge
history.
^ permalink raw reply
* Problem resolving an octopus merge conflict
From: Sean @ 2006-01-11 6:51 UTC (permalink / raw)
To: git
Hi folks,
After a failed regular merge you can fix up the conflicts by hand and then
do a commit; the proper parents for the merge will be picked up from
MERGE_HEADS. However, after a failed octopus merge this file doesn't
exist even though conflict markers _do_ exist in the appropriate files. A
little test case is given below:
mkdir otest
cd otest
git init-db
echo A > file
git add file
git commit -m "new file"
git checkout -b linus
echo B > file
git commit -a -m "B file"
git checkout -b torvalds master
echo C > file
git commit -a -m "C file"
git checkout master
git pull . linus torvalds
At which point you'll get back:
defaulting to local storage area
Committing initial tree a9e3325a07117aa5381e044a8d96c26eb30d729d
Trying simple merge with 87915efc19fb0a71f88c1da6f7da0e4454f32a68
Trying simple merge with ec835c64be51803fb46f82c97b266cc60a0b04b7
Simple merge did not work, trying automatic merge.
Auto-merging file
merge: warning: conflicts during merge
ERROR: Merge conflict in file
fatal: merge program failed
No merge strategy handled the merge.
The "file" will contain:
<<<<<<< .merge_file_e7oHn1
C
=======
B
>>>>>>> .merge_file_6Z4LD0
After fixing this up though, git-commit won't see this as a merge commit
and won't add the proper parent linkages. I'm not sure at this point
what the proper fix should be or if this is just pilot error.
Thanks,
Sean
^ permalink raw reply
* Re: [PATCH] Exec git programs without using PATH.
From: Junio C Hamano @ 2006-01-11 6:13 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Andreas Ericsson, git
In-Reply-To: <1136945538.11717.643.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> exec_cmd.c | 118
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a giveaway sign that your MUA is wrapping lines, so
please double-check before sending things out next time around.
It seems yours is not as bad as others I've seen; I could manage
to trivially hand-edit to make it appliable (although I am
inclined to ask you to polish it a bit further).
> +ifneq ($(shell cat .exec_cmd.gitexecdir 2>/dev/null),$(gitexecdir))
> +.PHONY: exec_cmd.c
> +$(shell echo $(gitexecdir) > .exec_cmd.gitexecdir)
> +endif
Although this check is much better than the last round, I changed
my mind about this part. We do not do the equivalent checks and
rebuild when somebody once builds with NO_OPENSSL and then tries
to rebuild without, or for any other compile time configuration
(template_dir, for example). Ideally we _could_ keep track of
all of them but I suspect that would be an overkill, so I am
inclined to drop this part.
We need to make sure that we clean .exec_cmd.gitexecdir on the
clean: target in the Makefile, if we _were_ to keep this, OTOH.
> +exec_cmd.o: CFLAGS+=-DGIT_EXEC_PATH=\"$(gitexecdir)\"
Please do not override CFLAGS like this; it breaks this common
usage:
$ make CFLAGS='-g -O1' exec_cmd.o
> diff --git a/exec_cmd.c b/exec_cmd.c
> +void git_set_exec_path(const char *exec_path)
> +{
> + current_exec_path = exec_path;
> +}
I've always wondered what we should do when --exec-path is given
more than once, but you decided it for me. I agree that
silently overwriting is just fine.
> + const char *paths[] = { current_exec_path,
> + getenv("GIT_EXEC_PATH"),
> + builtin_exec_path,
> + NULL };
I do not think you need the last NULL element in paths[] here,
given what the loop that uses this array does.
> + for (i = 0; i < 4; ++i) {
If your paths[] is fixed size, please do this instead:
for (i = 0; sizeof(paths)/sizeof(paths[0]); i++)
Then I do not have to remember that I need to update "4" when I
update paths[].
> diff --git a/exec_cmd.h b/exec_cmd.h
> +extern const char* git_exec_path();
ANSI C please: extern const char* git_exec_path(void);
> diff --git a/git.c b/git.c
> if (errno == ENOENT)
> - cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
> + cmd_usage(git_exec_path(), "'%s' is not a git-command",
> + argv[i]);
You have assigned to exec_path before the failed execv_git_cmd()
already; I think change in this line is unneeded.
> diff --git a/receive-pack.c b/receive-pack.c
> index f847ec2..8e78e32 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -257,7 +257,7 @@ static void read_head_info(void)
>
> static const char *unpack(int *error_code)
> {
> - int code = run_command(unpacker, NULL);
> + int code = run_command_v_opt(1, &unpacker, RUN_GIT_CMD);
This one is questionable; run_command_v_opt() calls
execv_git_cmd() which expects the second argument of
run_command_v_opt() to be NULL terminated, doesn't it?
> diff --git a/shell.c b/shell.c
> index cd31618..0d4891f 100644
> --- a/shell.c
> +++ b/shell.c
> @@ -12,7 +12,7 @@ static int do_generic_cmd(const char *me
> my_argv[1] = arg;
> my_argv[2] = NULL;
>
> - return execvp(me, (char**) my_argv);
> + return execv_git_cmd((char**) my_argv);
> }
Here my_argv comes from cmd_list[] which has "git-" prefix to
their command name, but I thought your exec[vl]_git_cmd() took
command names without.
Here is my suggestion on top of your patch, summarizing all of
the above comments.
-- >8 --
diff --git a/Makefile b/Makefile
index e7c7763..6694627 100644
--- a/Makefile
+++ b/Makefile
@@ -185,16 +185,6 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
-
-# .exec_cmd.gitexecdir stores $(gitexecir) used to compile exec_cmd.o
-# If it has changed, store the new value and force exec_cmd.o to be rebuilt
-ifneq ($(shell cat .exec_cmd.gitexecdir 2>/dev/null),$(gitexecdir))
-.PHONY: exec_cmd.c
-$(shell echo $(gitexecdir) > .exec_cmd.gitexecdir)
-endif
-
-exec_cmd.o: CFLAGS+=-DGIT_EXEC_PATH=\"$(gitexecdir)\"
-
# Shell quote;
# Result of this needs to be placed inside ''
shq = $(subst ','\'',$(1))
@@ -423,6 +413,8 @@ git$X git.spec \
%.o: %.S
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
+exec_cmd.o: ALL_CFLAGS += -DGIT_EXEC_PATH=\"$(gitexecdir)\"
+
git-%$X: %.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
diff --git a/exec_cmd.c b/exec_cmd.c
index a3bd40a..55af33b 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -36,10 +36,9 @@ int execv_git_cmd(char **argv)
int len, err, i;
const char *paths[] = { current_exec_path,
getenv("GIT_EXEC_PATH"),
- builtin_exec_path,
- NULL };
+ builtin_exec_path };
- for (i = 0; i < 4; ++i) {
+ for (i = 0; i < sizeof(paths)/sizeof(paths[0]); ++i) {
const char *exec_dir = paths[i];
if (!exec_dir) continue;
diff --git a/exec_cmd.h b/exec_cmd.h
index 06d5ec3..5150ee2 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,7 +2,7 @@
#define __GIT_EXEC_CMD_H_
extern void git_set_exec_path(const char *exec_path);
-extern const char* git_exec_path();
+extern const char* git_exec_path(void);
extern int execv_git_cmd(char **argv); /* NULL terminated */
extern int execl_git_cmd(char *cmd, ...);
diff --git a/git.c b/git.c
index fdd02ed..e3a0b59 100644
--- a/git.c
+++ b/git.c
@@ -285,10 +285,10 @@ int main(int argc, char **argv, char **e
execv_git_cmd(argv + i);
if (errno == ENOENT)
- cmd_usage(git_exec_path(), "'%s' is not a git-command",
- argv[i]);
+ cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
+
return 1;
}
diff --git a/receive-pack.c b/receive-pack.c
index 8e78e32..6120dbe 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 const char unpacker[] = "git-unpack-objects";
+static char *unpacker[] = { "git-unpack-objects", NULL };
static int report_status = 0;
@@ -257,7 +257,7 @@ static void read_head_info(void)
static const char *unpack(int *error_code)
{
- int code = run_command_v_opt(1, &unpacker, RUN_GIT_CMD);
+ int code = run_command_v_opt(1, unpacker, RUN_GIT_CMD);
*error_code = 0;
switch (code) {
diff --git a/shell.c b/shell.c
index 0d4891f..d40dfe4 100644
--- a/shell.c
+++ b/shell.c
@@ -7,8 +7,10 @@ static int do_generic_cmd(const char *me
if (!arg || !(arg = sq_dequote(arg)))
die("bad argument");
+ if (strncmp(me, "git-", 4))
+ die("bad command");
- my_argv[0] = me;
+ my_argv[0] = me + 4;
my_argv[1] = arg;
my_argv[2] = NULL;
^ permalink raw reply related
* Re: [PATCH] glossary: explain "master" and "origin"
From: Junio C Hamano @ 2006-01-11 6:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J. Bruce Fields, git, junkio
In-Reply-To: <Pine.LNX.4.63.0601102238570.802@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> P.S.: I just noted that some of the tabs were turned into spaces. Does
> asciidoc mind?
Probably not, but I do so I fixed them up myself.
^ permalink raw reply
* [ANNOUNCE] GIT 1.1.1
From: Junio C Hamano @ 2006-01-11 4:43 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.1.1 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.1.1.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.1.1-1.$arch.rpm (RPM)
This is primarily to fix the build problems with RPM and tarball
releases. I owe a big thanks to Peter Anvin for the fix.
----------------------------------------------------------------
Changes since v1.1.0 are as follows:
H. Peter Anvin:
For release tarballs, include the proper version
Johannes Schindelin:
glossary: explain "master" and "origin"
Junio C Hamano:
GIT-VERSION-GEN: detect dirty tree and mark the version accordingly.
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Luben Tuikov @ 2006-01-11 3:32 UTC (permalink / raw)
To: Kyle Moffett, Martin Langhoff
Cc: Luben Tuikov, Brown, Len, Luck, Tony, Junio C Hamano,
Linus Torvalds, David S. Miller,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, LKML Kernel, Andrew Morton,
Git Mailing List
In-Reply-To: <252A408D-0B42-49F3-92BC-B80F94F19F40-ee4meeAH724@public.gmane.org>
--- Kyle Moffett <mrmacman_g4-ee4meeAH724@public.gmane.org> wrote:
> they're totally irrelevant. This is why it's useful to only pull
> mainline into your tree (EX: ACPI) when you functionally depend on
> changes there (as Linus so eloquently expounded upon).
Sometimes the dependency is _behavioural_. For example certain
behaviour of other modules of the kernel changed and you want
to test that your module works ok with them under different
behaviour. In which case you may or may not have to
change your code after the fact.
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git-bisect is magical
From: Linus Torvalds @ 2006-01-11 2:58 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq1o88$1bm$1@sea.gmane.org>
On Tue, 10 Jan 2006, walt wrote:
>
> Linus Torvalds wrote:
> [...]
> > So when you say "git checkout origin", it actually _switches_ to the
> > origin branch (which is just my state) and checks that out.
>
> I think we are finally homing in on the very roots of my ignorance!
>
> When you use the word 'switches' my eyes go glassy, just like when
> my wife starts telling me everything I've done wrong today...
Ahhah.
> Please --> what am I switching *from* when I switch to 'origin'?
> (Think: this guy is a total dumbshit! How can I possibly dumb-
> down this basic knowledge any dumber?)
Ok, this clearly isn't described well enough in any docs, so let me try,
and hopefully somebody (hint hint) will go "Ahh, I wish that had been
described in xyz - here's a patch to do so".
Anyway, the notion of multiple "branches" aka "heads of development" is
pretty ingrained in git. It's really how _everything_ subtle gets done
(merging, you name it - sometimes the branch may be a temporary unnamed
head that is just inside a script, but the _concept_ is always there).
There's one _special_ branch, which is the "active" one. The only git
trees without an active branch are the so-called "bare" git trees, which
are the .git directory contents directly, without any checked-out state.
Those are only used for distribution - no development can ever happen in
them, because they simply don't have any active branch to do development
_in_.
But for any normal git repository, you'll have one active branch, which is
the one that your working directory actually represents. It's also the one
we call "HEAD", since the HEAD thing is the thing that points to the
active branch.
Your HEAD can point to _any_ branch, but the default one is called
"master". That's the branch you get when you clone another repository, or
when you just start a new git repository from scratch with "git-init-db".
But you can "switch" between branches at any time by just doing a simple
"git checkout <branchname>". That will conceptually totally blow away your
working directory contents (well, all of it that git knows about, anyway),
and replace them with the contents that the _other_ branch contains. Now,
I say "conceptually", because in practice this is heavily optimized, so
that any files that don't change aren't actually re-written, so you can
switch between two branches that are similar quite cheaply.
So when you did "git checkout origin", you basically blew away all the
development you had done in the default "master" branch, and switched to
_another_ branch. The "origin" branch is the one that is generated for you
automatically when you clone a repository from somewhere else: it
initially contains the state of that other repository at the time of the
clone, and a "git pull origin" will actually both "fetch" that branch (so
that the "origin" branch is kept up-to-date with the original source)
_and_ merge that branch into your HEAD (normally "master").
> I know this is really bone-head-basic-stuff, but I'm quite sure
> that this lies at the heart of my confusion.
>
> When I finally understand this kindergarten material I can graduate
> to first grade :o)
Well, at least _some_ of this is described in Documentation/git-pull.txt
and Documentation/tutorial.txt. So if you haven't looked into those
before, try them now. And if you have, they clearly need more effort.
I'm really bad at documentation. I'm more than happy trying to answer
emailed questions (at least if I get the feeling that the person asking
the questions is really trying to learn, which you've done admirably), but
that doesn't mean that I'm good at writing the docs. So I'm hoping that
some of this can find itself into a FAQ or one of the existing docs,
thanks to somebody else editing it..
Linus
^ permalink raw reply
* Re: git-bisect is magical
From: Junio C Hamano @ 2006-01-11 2:47 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq1o88$1bm$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
> Linus Torvalds wrote:
> [...]
>> So when you say "git checkout origin", it actually _switches_ to the
>> origin branch (which is just my state) and checks that out.
>
> Please --> what am I switching *from* when I switch to 'origin'?
Short version: if you have only two branches "master" and
"origin", then obviously there is only one "the other one" ;-).
Longer version:
At the very beginning, you started your repository like this:
$ git clone git://git.kernel.org/some/where mine
$ cd mine
You can say:
$ git branch
And you would see:
$ git branch
* master
origin
So you have two branches, and you are on "master" right now.
Your working tree files are associated with one branch at any
moment, and "git branch" shows you which branch you are on.
That branch is "the current branch". When you make your
commits, you will commit into that branch. The commit-producing
commands include "git commit", "git am", "git pull", "git
merge", "git revert" and "git cherry-pick". They all create a
new commit on your "current branch". The difference among them
is where the commit you create takes the modifications from
(commit from the index file and the working tree, am from a
mailbox, pull and merge from a different branch, and revert and
cherry-pick from an existing commit).
You usually work in your "master" branch. But you do not have
to. Suppose you are working on maintaining some product, and
you have a couple of trivial bugfixes you can make and one
rather involved enhancement. What you could do is to have more
than one branches, and use "master" for what are ready to be
consumed by other people, and another branch for your
developments.
Your repository at one point might look like this:
$ git show-branch
* [master] trivial fix #2
! [devel] work in progress #3
--
+ [devel] work in progress #3
+ [devel^] work in progress #2
+ [devel~2] work in progress #1
+ [master] trivial fix #2
+ [master^] trivial fix #1
++ [master~2] released frotz gadget
You are on the "master" branch, and committed two trivial fixes
on top of it since your last release. But in the meantime you
found time to do independent enhancements, not yet finished but
slowly progressing. You hope to be able to complete the
development and include that in the master branch eventually,
but not yet.
How you would end up to something like above would go like this:
1. You have just released frotz gadget. Your "master" branch
is at that commit, and you do not have the "devel" branch
yet.
2. You are inspired by somebody to enhance frotz in a novel
way. You start hacking and accumulate some changes in the
working tree files, but now you realize it will be a bigger
task than you initially thought. In the meantime, you got a
couple of bug reports and you think you know how to fix them
trivially. But unfortunately, your working tree files are
currently in a great mess. Then:
$ git checkout -b devel
This creates a new branch ("devel") based on the current
branch head (remember, you were on "master" branch), and
switches to that new branch. It is a short-hand for the two
command sequence:
$ git branch devel
$ git checkout devel
This takes your working tree changes with you, so at this
point if you do "git diff", you will see your changes. You
commit this mess (do not worry about "presentable history"
yet; you will be cleaning up the mess later anyway before
you merge).
$ git add new-files-you-created
$ git commit -a -m 'work in progress #1'
3. Now you can switch mood and can work on the trivial fixes.
Go back to the "master" branch:
$ git checkout master
you'll notice that all the mess you made while working on
devel has been cleaned up --- WIP edits are gone, and if you
made new files for "devel" they are gone too. You start
from the state immediately after release, and work on fixes,
and commit:
$ edit for trivial fix number 1
$ git commit -a -m 'trivial fix #1'
$ edit for trivial fix number 2
$ git commit -a -m 'trivial fix #2'
4. Now fixes are out of your way, you can go back to work on
the enhancements. The same thing as step 3.
$ git checkout devel
$ edit / test / commit
Eventually what you do in your devel branch comes to maturity
and ready for public consumption. How would you make sure when?
For that, you would create a throw-away test branch and try
things out:
$ git branch -f test master
$ git checkout test
$ git merge 'development trial' test devel
This would create something like this:
$ git show-branch
! [master] trivial fix #2
! [devel] work in progress #3
* [test] development trial
---
+ [test] development trial
++ [devel] work in progress #3
++ [devel^] work in progress #2
++ [devel~2] work in progress #1
+ + [master] trivial fix #2
+ + [master^] trivial fix #1
+++ [master~2] released frotz gadget
You merged "devel" and "master" in "test" branch, so that you
can test your development along with the other fixes you had in
the "master" branch since your "devel" branch forked. Try
things out and if you find the result satisfactory, then you
know what you have in "devel" is good for public consumption.
There are three ways to bring the "devel" into "master" at this
moment. It depends on how much you care about clean history.
A) just merge.
$ git checkout master
$ git pull . devel
This is the simplest, but you would see all the real history
in "devel" branch, things like "work in progress #n" commit
log messages.
B) refactor and linearize.
$ git format-patch -k -m -o ./+redo master..devel
This leaves a patchfile per commit in devel branch in +redo/
directory. You can edit the commit log message and patch
just as if you are preparing them for e-mail submission to
another project maintainer. Once you are done editing:
$ git checkout master
$ git am -k -3 ./+redo/0*.txt
to apply them on top of the master branch.
C) linearize without refactoring.
$ git checkout devel
$ git rebase master
$ git checkout master
$ git pull . devel
This "rebases" the development branch (the first two steps),
and then pulls the result into the "master" branch (the
rest). It should give you the same result as approach B) if
you do not edit your +redo/ files at all.
Once you are done, you can clean up by
$ git branch -D test devel
^ permalink raw reply
* [PATCH] Exec git programs without using PATH.
From: Michal Ostrowski @ 2006-01-11 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vd5iz4mt7.fsf@assigned-by-dhcp.cox.net>
The git suite may not be in PATH (and thus programs such as
git-send-pack could not exec git-rev-list). Thus there is a need for
logic that will locate these programs. Modifying PATH is not
desirable as it result in behavior differing from the user's
intentions, as we may end up prepending "/usr/bin" to PATH.
- git C programs will use exec*_git_cmd() APIs to exec sub-commands.
- exec*_git_cmd() will execute a git program by searching for it in
the following directories:
1. --exec-path (as used by "git")
2. The GIT_EXEC_PATH environment variable.
3. $(gitexecdir) as set in Makefile (default value $(bindir)).
- git potty will modify PATH as before to enable shell scripts to
invoke "git-foo" commands.
Ideally, shell scripts should use the git potty to become independent of
PATH, and then modifying PATH will not be necessary.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
Makefile | 21 ++++++++--
daemon.c | 3 +
exec_cmd.c | 118
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
exec_cmd.h | 10 +++++
fetch-clone.c | 7 +--
git.c | 54 ++++++--------------------
receive-pack.c | 2 -
run-command.c | 9 +++-
run-command.h | 2 -
send-pack.c | 8 ++--
shell.c | 2 -
upload-pack.c | 7 ++-
12 files changed, 181 insertions(+), 62 deletions(-)
create mode 100644 exec_cmd.c
create mode 100644 exec_cmd.h
d6dbbb5b9b47c37f44c3494962b9fa534677729f
diff --git a/Makefile b/Makefile
index c9c15b5..912c223 100644
--- a/Makefile
+++ b/Makefile
@@ -68,6 +68,7 @@ ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
+gitexecdir = $(prefix)/bin
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -141,7 +142,7 @@ PROGRAMS = \
git-describe$X
# what 'all' will build and 'install' will install.
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -173,7 +174,7 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o count-delta.o csum-file.o \
- date.o diff-delta.o entry.o ident.o index.o \
+ date.o diff-delta.o entry.o exec_cmd.o ident.o index.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
@@ -184,6 +185,16 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
+
+# .exec_cmd.gitexecdir stores $(gitexecir) used to compile exec_cmd.o
+# If it has changed, store the new value and force exec_cmd.o to be
rebuilt
+ifneq ($(shell cat .exec_cmd.gitexecdir 2>/dev/null),$(gitexecdir))
+.PHONY: exec_cmd.c
+$(shell echo $(gitexecdir) > .exec_cmd.gitexecdir)
+endif
+
+exec_cmd.o: CFLAGS+=-DGIT_EXEC_PATH=\"$(gitexecdir)\"
+
# Shell quote;
# Result of this needs to be placed inside ''
shq = $(subst ','\'',$(1))
@@ -366,13 +377,13 @@ LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS)
+all: $(ALL_PROGRAMS) git$X
all:
$(MAKE) -C templates
git$X: git.c $(LIB_FILE)
- $(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
+ $(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -468,7 +479,9 @@ check:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
$(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) git$X $(call shellquote,$(DESTDIR)$(gitexecdir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
diff --git a/daemon.c b/daemon.c
index 3bd1426..bb014fa 100644
--- a/daemon.c
+++ b/daemon.c
@@ -9,6 +9,7 @@
#include <syslog.h>
#include "pkt-line.h"
#include "cache.h"
+#include "exec_cmd.h"
static int log_syslog;
static int verbose;
@@ -227,7 +228,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf,
".", NULL);
+ execl_git_cmd("upload-pack", "--strict", timeout_buf, ".", NULL);
return -1;
}
diff --git a/exec_cmd.c b/exec_cmd.c
new file mode 100644
index 0000000..a3bd40a
--- /dev/null
+++ b/exec_cmd.c
@@ -0,0 +1,118 @@
+#include "cache.h"
+#include "exec_cmd.h"
+#define MAX_ARGS 32
+
+extern char **environ;
+static const char *builtin_exec_path = GIT_EXEC_PATH;
+static const char *current_exec_path = NULL;
+
+void git_set_exec_path(const char *exec_path)
+{
+ current_exec_path = exec_path;
+}
+
+
+/* Returns the highest-priority, location to look for git programs. */
+const char *git_exec_path()
+{
+ const char *env;
+
+ if (current_exec_path)
+ return current_exec_path;
+
+ env = getenv("GIT_EXEC_PATH");
+ if (env) {
+ return env;
+ }
+
+ return builtin_exec_path;
+}
+
+
+int execv_git_cmd(char **argv)
+{
+ char git_command[PATH_MAX + 1];
+ char *tmp;
+ int len, err, i;
+ const char *paths[] = { current_exec_path,
+ getenv("GIT_EXEC_PATH"),
+ builtin_exec_path,
+ NULL };
+
+ for (i = 0; i < 4; ++i) {
+ const char *exec_dir = paths[i];
+ if (!exec_dir) continue;
+
+ if (*exec_dir != '/') {
+ if (!getcwd(git_command, sizeof(git_command))) {
+ fprintf(stderr, "git: cannot determine "
+ "current directory\n");
+ exit(1);
+ }
+ len = strlen(git_command);
+
+ /* Trivial cleanup */
+ while (!strncmp(exec_dir, "./", 2)) {
+ exec_dir += 2;
+ while (*exec_dir == '/')
+ exec_dir++;
+ }
+ snprintf(git_command + len, sizeof(git_command) - len,
+ "/%s", exec_dir);
+ } else {
+ strcpy(git_command, exec_dir);
+ }
+
+ len = strlen(git_command);
+ len += snprintf(git_command + len, sizeof(git_command) - len,
+ "/git-%s", argv[0]);
+
+ if (sizeof(git_command) <= len) {
+ fprintf(stderr,
+ "git: command name given is too long.\n");
+ break;
+ }
+
+ /* argv[0] must be the git command, but the argv array
+ * belongs to the caller, and my be reused in
+ * subsequent loop iterations. Save argv[0] and
+ * restore it on error.
+ */
+
+ tmp = argv[0];
+ argv[0] = git_command;
+
+ /* execve() can only ever return if it fails */
+ execve(git_command, argv, environ);
+
+ err = errno;
+
+ argv[0] = tmp;
+ }
+ return -1;
+
+}
+
+
+int execl_git_cmd(char *cmd,...)
+{
+ int argc;
+ char *argv[MAX_ARGS + 1];
+ char *arg;
+ va_list param;
+
+ va_start(param, cmd);
+ argv[0] = cmd;
+ argc = 1;
+ while (argc < MAX_ARGS) {
+ arg = argv[argc++] = va_arg(param, char *);
+ if (!arg)
+ break;
+ }
+ va_end(param);
+ if (MAX_ARGS <= argc)
+ return error("too many args to run %s", cmd);
+
+ argv[argc] = NULL;
+ return execv_git_cmd(argv);
+}
diff --git a/exec_cmd.h b/exec_cmd.h
new file mode 100644
index 0000000..06d5ec3
--- /dev/null
+++ b/exec_cmd.h
@@ -0,0 +1,10 @@
+#ifndef __GIT_EXEC_CMD_H_
+#define __GIT_EXEC_CMD_H_
+
+extern void git_set_exec_path(const char *exec_path);
+extern const char* git_exec_path();
+extern int execv_git_cmd(char **argv); /* NULL terminated */
+extern int execl_git_cmd(char *cmd, ...);
+
+
+#endif /* __GIT_EXEC_CMD_H_ */
diff --git a/fetch-clone.c b/fetch-clone.c
index f46fe6e..859f400 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
#include <sys/wait.h>
static int finish_pack(const char *pack_tmp_name, const char *me)
@@ -27,8 +28,7 @@ static int finish_pack(const char *pack_
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- execlp("git-index-pack","git-index-pack",
- "-o", idx, pack_tmp_name, NULL);
+ execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, NULL);
error("cannot exec git-index-pack <%s> <%s>",
idx, pack_tmp_name);
exit(1);
@@ -105,8 +105,7 @@ int receive_unpack_pack(int fd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-unpack-objects", "git-unpack-objects",
- quiet ? "-q" : NULL, NULL);
+ execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
die("git-unpack-objects exec failed");
}
close(fd[0]);
diff --git a/git.c b/git.c
index 5e7da74..fdd02ed 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@
#include <stdarg.h>
#include <sys/ioctl.h>
#include "git-compat-util.h"
+#include "exec_cmd.h"
#ifndef PATH_MAX
# define PATH_MAX 4096
@@ -233,14 +234,11 @@ int main(int argc, char **argv, char **e
{
char git_command[PATH_MAX + 1];
char wd[PATH_MAX + 1];
- int i, len, show_help = 0;
- char *exec_path = getenv("GIT_EXEC_PATH");
+ int i, show_help = 0;
+ char *exec_path;
getcwd(wd, PATH_MAX);
- if (!exec_path)
- exec_path = GIT_EXEC_PATH;
-
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -256,10 +254,11 @@ int main(int argc, char **argv, char **e
if (!strncmp(arg, "exec-path", 9)) {
arg += 9;
- if (*arg == '=')
+ if (*arg == '=') {
exec_path = arg + 1;
- else {
- puts(exec_path);
+ git_set_exec_path(exec_path);
+ } else {
+ puts(git_exec_path());
exit(0);
}
}
@@ -275,48 +274,21 @@ int main(int argc, char **argv, char **e
if (i >= argc || show_help) {
if (i >= argc)
- cmd_usage(exec_path, NULL);
+ cmd_usage(git_exec_path(), NULL);
show_man_page(argv[i]);
}
- if (*exec_path != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr,
- "git: cannot determine current directory\n");
- exit(1);
- }
- len = strlen(git_command);
+ exec_path = git_exec_path();
+ prepend_to_path(exec_path, strlen(exec_path));
- /* Trivial cleanup */
- while (!strncmp(exec_path, "./", 2)) {
- exec_path += 2;
- while (*exec_path == '/')
- exec_path++;
- }
- snprintf(git_command + len, sizeof(git_command) - len,
- "/%s", exec_path);
- }
- else
- strcpy(git_command, exec_path);
- len = strlen(git_command);
- prepend_to_path(git_command, len);
-
- len += snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[i]);
- if (sizeof(git_command) <= len) {
- fprintf(stderr, "git: command name given is too long.\n");
- exit(1);
- }
-
- /* execve() can only ever return if it fails */
- execve(git_command, &argv[i], envp);
+ execv_git_cmd(argv + i);
if (errno == ENOENT)
- cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
+ cmd_usage(git_exec_path(), "'%s' is not a git-command",
+ argv[i]);
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
-
return 1;
}
diff --git a/receive-pack.c b/receive-pack.c
index f847ec2..8e78e32 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -257,7 +257,7 @@ static void read_head_info(void)
static const char *unpack(int *error_code)
{
- int code = run_command(unpacker, NULL);
+ int code = run_command_v_opt(1, &unpacker, RUN_GIT_CMD);
*error_code = 0;
switch (code) {
diff --git a/run-command.c b/run-command.c
index 8bf5922..b3d287e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include <sys/wait.h>
+#include "exec_cmd.h"
int run_command_v_opt(int argc, char **argv, int flags)
{
@@ -13,9 +14,13 @@ int run_command_v_opt(int argc, char **a
int fd = open("/dev/null", O_RDWR);
dup2(fd, 0);
dup2(fd, 1);
- close(fd);
+ close(fd);
+ }
+ if (flags & RUN_GIT_CMD) {
+ execv_git_cmd(argv);
+ } else {
+ execvp(argv[0], (char *const*) argv);
}
- execvp(argv[0], (char *const*) argv);
die("exec %s failed.", argv[0]);
}
for (;;) {
diff --git a/run-command.h b/run-command.h
index 2469eea..ef3ee05 100644
--- a/run-command.h
+++ b/run-command.h
@@ -12,7 +12,7 @@ enum {
};
#define RUN_COMMAND_NO_STDIO 1
-
+#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
int run_command_v_opt(int argc, char **argv, int opt);
int run_command_v(int argc, char **argv);
int run_command(const char *cmd, ...);
diff --git a/send-pack.c b/send-pack.c
index cd36193..4a420a6 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -26,11 +26,11 @@ static int is_zero_sha1(const unsigned c
static void exec_pack_objects(void)
{
static char *args[] = {
- "git-pack-objects",
+ "pack-objects",
"--stdout",
NULL
};
- execvp("git-pack-objects", args);
+ execv_git_cmd(args);
die("git-pack-objects exec failed (%s)", strerror(errno));
}
@@ -39,7 +39,7 @@ static void exec_rev_list(struct ref *re
static char *args[1000];
int i = 0;
- args[i++] = "git-rev-list"; /* 0 */
+ args[i++] = "rev-list"; /* 0 */
args[i++] = "--objects"; /* 1 */
while (refs) {
char *buf = malloc(100);
@@ -58,7 +58,7 @@ static void exec_rev_list(struct ref *re
refs = refs->next;
}
args[i] = NULL;
- execvp("git-rev-list", args);
+ execv_git_cmd(args);
die("git-rev-list exec failed (%s)", strerror(errno));
}
diff --git a/shell.c b/shell.c
index cd31618..0d4891f 100644
--- a/shell.c
+++ b/shell.c
@@ -12,7 +12,7 @@ static int do_generic_cmd(const char *me
my_argv[1] = arg;
my_argv[2] = NULL;
- return execvp(me, (char**) my_argv);
+ return execv_git_cmd((char**) my_argv);
}
static struct commands {
diff --git a/upload-pack.c b/upload-pack.c
index 1834b6b..d198055 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -4,6 +4,7 @@
#include "tag.h"
#include "object.h"
#include "commit.h"
+#include "exec_cmd.h"
static const char upload_pack_usage[] = "git-upload-pack [--strict]
[--timeout=nn] <dir>";
@@ -60,7 +61,7 @@ static void create_pack_file(void)
close(0);
close(fd[0]);
close(fd[1]);
- *p++ = "git-rev-list";
+ *p++ = "rev-list";
*p++ = "--objects";
if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
@@ -79,13 +80,13 @@ static void create_pack_file(void)
buf += 41;
}
*p++ = NULL;
- execvp("git-rev-list", argv);
+ execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
}
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-pack-objects", "git-pack-objects", "--stdout", NULL);
+ execl_git_cmd("pack-objects", "--stdout", NULL);
die("git-upload-pack: unable to exec git-pack-objects");
}
--
0.99.9m-g5a22
^ permalink raw reply related
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-11 2:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vd5iz4mt7.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-01-10 at 16:42 -0800, Junio C Hamano wrote:
> Michal Ostrowski <mostrows@watson.ibm.com> writes:
>
> > How about searching for executables in the following places, and in this
> > order:
> >
> > 1. --exec-path setting, if any
> > 2. GIT_EXEC_PATH env var, if set
> > 3. PATH (never modified)
> > 4. Value of ${bindir} at build time
>
> and then make the rule for git things:
>
> 1. --exec-path
> 2. GIT_EXEC_PATH environment
> 3. $(gitexecdir)
>
> in this order. Non git things should just use $PATH without
> looking at anything else --- as long as a hook script calls a git
> wrapper (i.e. "git foo" not "git-foo") I think things should
> work fine.
>
The patch that follows implements your suggested search order and
includes suggested Makefile changes.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox