threads / discuss / 3470

Teach the "git" command to handle some commands internally

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

## tl;dr

5 messages between Feb 26, 2006 and Feb 27, 2006.

replies: 4people: 3as markdown or json

Linus Torvalds· Feb 26, 2006, 20:34 UTC · lore

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));
Junio C Hamano· Feb 26, 2006, 23:10 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@osdl.org> writes:
Show 8 quoted lines
> 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.
Linus Torvalds· Feb 26, 2006, 23:22 UTC · re: Junio C Hamano · lore

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

On Sun, 26 Feb 2006, Junio C Hamano wrote:
Show 7 quoted lines
> 
> > 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
Junio C Hamano· Feb 26, 2006, 23:46 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@osdl.org> writes:
Show 12 quoted lines
> 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.

Michal Ostrowski· Feb 27, 2006, 12:59 UTC · re: Junio C Hamano · lore

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

On Sun, 2006-02-26 at 15:46 -0800, Junio C Hamano wrote:
Show 21 quoted lines
> 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>

← back to recent threads