Teach the "git" command to handle some commands internally

Teach the "git" command to handle some commands internally

[Linus Torvalds]

This is another patch in the "prepare to do more in C" series, where the 
git wrapper command is taught about the notion of handling some 
functionality internally.

Right now, the only internal commands are "version" and "help", but the 
point being that we can now easily extend it to handle some of the trivial 
scripts internally. Things like "git log" and "git diff" wouldn't need 
separate external scripts any more.

This also implies that to support the old "git-log" and "git-diff" syntax, 
the "git" wrapper now automatically looks at the name it was executed as, 
and if it is "git-xxxx", it will assume that it is to internally do what 
"git xxxx" would do.

In other words, you can (once you implement an internal command) soft- or 
hard-link that command to the "git" wrapper command, and it will do the 
right thing, whether you use the "git xxxx" or the "git-xxxx" format.

There's one other change: the search order for external programs is 
modified slightly, so that the first entry remains GIT_EXEC_DIR, but the 
second entry is the same directory as the git wrapper itself was executed 
out of - if we can figure it out from argv[0], of course.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>

---

I personally think this is also a cleanup, but I'm cc'ing other people who 
have worked on the wrapper for comments. Maybe people hate it.

		Linus

---
diff --git a/git.c b/git.c
index 4616df6..993cd0d 100644
--- a/git.c
+++ b/git.c
@@ -230,62 +230,141 @@ static void show_man_page(char *git_cmd)
 	execlp("man", "man", page, NULL);
 }
 
+static int cmd_version(int argc, char **argv, char **envp)
+{
+	printf("git version %s\n", GIT_VERSION);
+	return 0;
+}
+
+static int cmd_help(int argc, char **argv, char **envp)
+{
+	char *help_cmd = argv[1];
+	if (!help_cmd)
+		cmd_usage(git_exec_path(), NULL);
+	show_man_page(help_cmd);
+	return 0;
+}
+
+#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+
+static void handle_internal_command(int argc, char **argv, char **envp)
+{
+	const char *cmd = argv[0];
+	static struct cmd_struct {
+		const char *cmd;
+		int (*fn)(int, char **, char **);
+	} commands[] = {
+		{ "version", cmd_version },
+		{ "help", cmd_help },
+	};
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(commands); i++) {
+		struct cmd_struct *p = commands+i;
+		if (strcmp(p->cmd, cmd))
+			continue;
+		exit(p->fn(argc, argv, envp));
+	}
+}
+
 int main(int argc, char **argv, char **envp)
 {
+	char *cmd = argv[0];
+	char *slash = strrchr(cmd, '/');
 	char git_command[PATH_MAX + 1];
-	char wd[PATH_MAX + 1];
-	int i, show_help = 0;
-	const char *exec_path;
+	const char *exec_path = NULL;
 
-	getcwd(wd, PATH_MAX);
+	/*
+	 * Take the basename of argv[0] as the command
+	 * name, and the dirname as the default exec_path
+	 * if it's an absolute path and we don't have
+	 * anything better.
+	 */
+	if (slash) {
+		*slash++ = 0;
+		if (*cmd == '/')
+			exec_path = cmd;
+		cmd = slash;
+	}
 
-	for (i = 1; i < argc; i++) {
-		char *arg = argv[i];
+	/*
+	 * "git-xxxx" is the same as "git xxxx", but we obviously:
+	 *
+	 *  - cannot take flags in between the "git" and the "xxxx".
+	 *  - cannot execute it externally (since it would just do
+	 *    the same thing over again)
+	 *
+	 * So we just directly call the internal command handler, and
+	 * die if that one cannot handle it.
+	 */
+	if (!strncmp(cmd, "git-", 4)) {
+		cmd += 4;
+		argv[0] = cmd;
+		handle_internal_command(argc, argv, envp);
+		die("cannot handle %s internally", cmd);
+	}
 
-		if (!strcmp(arg, "help")) {
-			show_help = 1;
-			continue;
-		}
+	/* Default command: "help" */
+	cmd = "help";
 
-		if (strncmp(arg, "--", 2))
+	/* Look for flags.. */
+	while (argc > 1) {
+		cmd = *++argv;
+		argc--;
+
+		if (strncmp(cmd, "--", 2))
 			break;
 
-		arg += 2;
+		cmd += 2;
+
+		/*
+		 * For legacy reasons, the "version" and "help"
+		 * commands can be written with "--" prepended
+		 * to make them look like flags.
+		 */
+		if (!strcmp(cmd, "help"))
+			break;
+		if (!strcmp(cmd, "version"))
+			break;
 
-		if (!strncmp(arg, "exec-path", 9)) {
-			arg += 9;
-			if (*arg == '=') {
-				exec_path = arg + 1;
-				git_set_exec_path(exec_path);
-			} else {
-				puts(git_exec_path());
-				exit(0);
+		/*
+		 * Check remaining flags (which by now must be
+		 * "--exec-path", but maybe we will accept
+		 * other arguments some day)
+		 */
+		if (!strncmp(cmd, "exec-path", 9)) {
+			cmd += 9;
+			if (*cmd == '=') {
+				git_set_exec_path(cmd + 1);
+				continue;
 			}
-		}
-		else if (!strcmp(arg, "version")) {
-			printf("git version %s\n", GIT_VERSION);
+			puts(git_exec_path());
 			exit(0);
 		}
-		else if (!strcmp(arg, "help"))
-			show_help = 1;
-		else if (!show_help)
-			cmd_usage(NULL, NULL);
-	}
-
-	if (i >= argc || show_help) {
-		if (i >= argc)
-			cmd_usage(git_exec_path(), NULL);
-
-		show_man_page(argv[i]);
+		cmd_usage(NULL, NULL);
 	}
+	argv[0] = cmd;
 
+	/*
+	 * We search for git commands in the following order:
+	 *  - git_exec_path()
+	 *  - the path of the "git" command if we could find it
+	 *    in $0
+	 *  - the regular PATH.
+	 */
+	if (exec_path)
+		prepend_to_path(exec_path, strlen(exec_path));
 	exec_path = git_exec_path();
 	prepend_to_path(exec_path, strlen(exec_path));
 
-	execv_git_cmd(argv + i);
+	/* See if it's an internal command */
+	handle_internal_command(argc, argv, envp);
+
+	/* .. then try the external ones */
+	execv_git_cmd(argv);
 
 	if (errno == ENOENT)
-		cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
+		cmd_usage(exec_path, "'%s' is not a git-command", cmd);
 
 	fprintf(stderr, "Failed to run command '%s': %s\n",
 		git_command, strerror(errno));

Re: Teach the "git" command to handle some commands internally

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> This also implies that to support the old "git-log" and "git-diff" syntax, 
> the "git" wrapper now automatically looks at the name it was executed as, 
> and if it is "git-xxxx", it will assume that it is to internally do what 
> "git xxxx" would do.
>
> In other words, you can (once you implement an internal command) soft- or 
> hard-link that command to the "git" wrapper command, and it will do the 
> right thing, whether you use the "git xxxx" or the "git-xxxx" format.

I like this careful backward compatibility part.

> There's one other change: the search order for external programs is 
> modified slightly, so that the first entry remains GIT_EXEC_DIR, but the 
> second entry is the same directory as the git wrapper itself was executed 
> out of - if we can figure it out from argv[0], of course.

I am not sure about this part, though.

Re: Teach the "git" command to handle some commands internally

[Linus Torvalds]

On Sun, 26 Feb 2006, Junio C Hamano wrote:
> 
> > There's one other change: the search order for external programs is 
> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the 
> > second entry is the same directory as the git wrapper itself was executed 
> > out of - if we can figure it out from argv[0], of course.
> 
> I am not sure about this part, though.

Well, what it means is that _if_ you install all your "git" binaries in 
some directory that is not in your patch and is not GIT_EXEC_DIR, they 
will still magically work, assuming you don't do something strange.

IOW, you can do things like

	alias git=/opt/my-git/git

and all the "git" commands will automatically work fine, even if you 
didn't know at compile time where you would install them, and you didn't 
set GIT_EXEC_DIR at run-time. It will still first look in GIT_EXEC_DIR, 
but if that fails, it will take the git commands from /opt/my-git/ instead 
of from /usr/bin or whatever.

It seemed a nice thing to try to make the git wrapper execute whatever git 
version it was installed with, rather than depend on PATH.

But hey, it's only a couple of lines out of the whole thing, so you can 
certainly skip it (remove the

	if (exec_path)
		prepend_path(exec_path)

lines to disable it).

		Linus

Re: Teach the "git" command to handle some commands internally

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 26 Feb 2006, Junio C Hamano wrote:
>> 
>> > There's one other change: the search order for external programs is 
>> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the 
>> > second entry is the same directory as the git wrapper itself was executed 
>> > out of - if we can figure it out from argv[0], of course.
>> 
>> I am not sure about this part, though.
>
> Well, what it means is that _if_ you install all your "git" binaries in 
> some directory that is not in your patch and is not GIT_EXEC_DIR, they 
> will still magically work, assuming you don't do something strange.

I understood that part.  I was wondering if this change defeats
what Michal (you sensibly CC'ed your message to) wanted to do
earlier, going great length trying to avoid mucking with PATH
and "where-ever git itself is found" in the last round.  After
reviewing the change in 77cb17 commit, I realize my worry was
unfounded.

Re: Teach the "git" command to handle some commands internally

[Michal Ostrowski]

On Sun, 2006-02-26 at 15:46 -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > On Sun, 26 Feb 2006, Junio C Hamano wrote:
> >> 
> >> > There's one other change: the search order for external programs is 
> >> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the 
> >> > second entry is the same directory as the git wrapper itself was executed 
> >> > out of - if we can figure it out from argv[0], of course.
> >> 
> >> I am not sure about this part, though.
> >
> > Well, what it means is that _if_ you install all your "git" binaries in 
> > some directory that is not in your patch and is not GIT_EXEC_DIR, they 
> > will still magically work, assuming you don't do something strange.
> 
> I understood that part.  I was wondering if this change defeats
> what Michal (you sensibly CC'ed your message to) wanted to do
> earlier, going great length trying to avoid mucking with PATH
> and "where-ever git itself is found" in the last round.  After
> reviewing the change in 77cb17 commit, I realize my worry was
> unfounded.

The changes seem reasonable for now.  We can't avoid mucking with PATH
as long as we are going to be running shell scripts that depend on PATH
to invoke "git-xxx" or even "git xxx".  I don't seen any easy solution
to this that would not involve changing every script (albeit
mechanically) and would not be prone to lapses in discipline.

Any solution to this original problem (i.e. a special "PATH" for "git*")
would seem to be applicable to the behavior this patch introduces.


-- 
Michal Ostrowski <mostrows@watson.ibm.com>