{"thread":{"id":"3470","subject":"Teach the \"git\" command to handle some commands internally","startedAt":"2006-02-26T20:34:51Z","lastAt":"2006-02-27T12:59:58Z","messageCount":5,"participants":["Linus Torvalds","Junio C Hamano","Michal Ostrowski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16767","messageId":"Pine.LNX.4.64.0602261225500.22647@g5.osdl.org","threadId":"3470","inReplyTo":null,"subject":"Teach the \"git\" command to handle some commands internally","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-26T20:34:51Z","receivedAt":"2006-02-26T20:34:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nThis is another patch in the \"prepare to do more in C\" series, where the \ngit wrapper command is taught about the notion of handling some \nfunctionality internally.\n\nRight now, the only internal commands are \"version\" and \"help\", but the \npoint being that we can now easily extend it to handle some of the trivial \nscripts internally. Things like \"git log\" and \"git diff\" wouldn't need \nseparate external scripts any more.\n\nThis also implies that to support the old \"git-log\" and \"git-diff\" syntax, \nthe \"git\" wrapper now automatically looks at the name it was executed as, \nand if it is \"git-xxxx\", it will assume that it is to internally do what \n\"git xxxx\" would do.\n\nIn other words, you can (once you implement an internal command) soft- or \nhard-link that command to the \"git\" wrapper command, and it will do the \nright thing, whether you use the \"git xxxx\" or the \"git-xxxx\" format.\n\nThere's one other change: the search order for external programs is \nmodified slightly, so that the first entry remains GIT_EXEC_DIR, but the \nsecond entry is the same directory as the git wrapper itself was executed \nout of - if we can figure it out from argv[0], of course.\n\nSigned-off-by: Linus Torvalds \n\n---\n\nI personally think this is also a cleanup, but I'm cc'ing other people who \nhave worked on the wrapper for comments. Maybe people hate it.\n\n\t\tLinus\n\n---\ndiff --git a/git.c b/git.c\nindex 4616df6..993cd0d 100644\n--- a/git.c\n+++ b/git.c\n@@ -230,62 +230,141 @@ static void show_man_page(char *git_cmd)\n \texeclp(\"man\", \"man\", page, NULL);\n }\n \n+static int cmd_version(int argc, char **argv, char **envp)\n+{\n+\tprintf(\"git version %s\\n\", GIT_VERSION);\n+\treturn 0;\n+}\n+\n+static int cmd_help(int argc, char **argv, char **envp)\n+{\n+\tchar *help_cmd = argv[1];\n+\tif (!help_cmd)\n+\t\tcmd_usage(git_exec_path(), NULL);\n+\tshow_man_page(help_cmd);\n+\treturn 0;\n+}\n+\n+#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n+\n+static void handle_internal_command(int argc, char **argv, char **envp)\n+{\n+\tconst char *cmd = argv[0];\n+\tstatic struct cmd_struct {\n+\t\tconst char *cmd;\n+\t\tint (*fn)(int, char **, char **);\n+\t} commands[] = {\n+\t\t{ \"version\", cmd_version },\n+\t\t{ \"help\", cmd_help },\n+\t};\n+\tint i;\n+\n+\tfor (i = 0; i < ARRAY_SIZE(commands); i++) {\n+\t\tstruct cmd_struct *p = commands+i;\n+\t\tif (strcmp(p->cmd, cmd))\n+\t\t\tcontinue;\n+\t\texit(p->fn(argc, argv, envp));\n+\t}\n+}\n+\n int main(int argc, char **argv, char **envp)\n {\n+\tchar *cmd = argv[0];\n+\tchar *slash = strrchr(cmd, '/');\n \tchar git_command[PATH_MAX + 1];\n-\tchar wd[PATH_MAX + 1];\n-\tint i, show_help = 0;\n-\tconst char *exec_path;\n+\tconst char *exec_path = NULL;\n \n-\tgetcwd(wd, PATH_MAX);\n+\t/*\n+\t * Take the basename of argv[0] as the command\n+\t * name, and the dirname as the default exec_path\n+\t * if it's an absolute path and we don't have\n+\t * anything better.\n+\t */\n+\tif (slash) {\n+\t\t*slash++ = 0;\n+\t\tif (*cmd == '/')\n+\t\t\texec_path = cmd;\n+\t\tcmd = slash;\n+\t}\n \n-\tfor (i = 1; i < argc; i++) {\n-\t\tchar *arg = argv[i];\n+\t/*\n+\t * \"git-xxxx\" is the same as \"git xxxx\", but we obviously:\n+\t *\n+\t * - cannot take flags in between the \"git\" and the \"xxxx\".\n+\t * - cannot execute it externally (since it would just do\n+\t * the same thing over again)\n+\t *\n+\t * So we just directly call the internal command handler, and\n+\t * die if that one cannot handle it.\n+\t */\n+\tif (!strncmp(cmd, \"git-\", 4)) {\n+\t\tcmd += 4;\n+\t\targv[0] = cmd;\n+\t\thandle_internal_command(argc, argv, envp);\n+\t\tdie(\"cannot handle %s internally\", cmd);\n+\t}\n \n-\t\tif (!strcmp(arg, \"help\")) {\n-\t\t\tshow_help = 1;\n-\t\t\tcontinue;\n-\t\t}\n+\t/* Default command: \"help\" */\n+\tcmd = \"help\";\n \n-\t\tif (strncmp(arg, \"--\", 2))\n+\t/* Look for flags.. */\n+\twhile (argc > 1) {\n+\t\tcmd = *++argv;\n+\t\targc--;\n+\n+\t\tif (strncmp(cmd, \"--\", 2))\n \t\t\tbreak;\n \n-\t\targ += 2;\n+\t\tcmd += 2;\n+\n+\t\t/*\n+\t\t * For legacy reasons, the \"version\" and \"help\"\n+\t\t * commands can be written with \"--\" prepended\n+\t\t * to make them look like flags.\n+\t\t */\n+\t\tif (!strcmp(cmd, \"help\"))\n+\t\t\tbreak;\n+\t\tif (!strcmp(cmd, \"version\"))\n+\t\t\tbreak;\n \n-\t\tif (!strncmp(arg, \"exec-path\", 9)) {\n-\t\t\targ += 9;\n-\t\t\tif (*arg == '=') {\n-\t\t\t\texec_path = arg + 1;\n-\t\t\t\tgit_set_exec_path(exec_path);\n-\t\t\t} else {\n-\t\t\t\tputs(git_exec_path());\n-\t\t\t\texit(0);\n+\t\t/*\n+\t\t * Check remaining flags (which by now must be\n+\t\t * \"--exec-path\", but maybe we will accept\n+\t\t * other arguments some day)\n+\t\t */\n+\t\tif (!strncmp(cmd, \"exec-path\", 9)) {\n+\t\t\tcmd += 9;\n+\t\t\tif (*cmd == '=') {\n+\t\t\t\tgit_set_exec_path(cmd + 1);\n+\t\t\t\tcontinue;\n \t\t\t}\n-\t\t}\n-\t\telse if (!strcmp(arg, \"version\")) {\n-\t\t\tprintf(\"git version %s\\n\", GIT_VERSION);\n+\t\t\tputs(git_exec_path());\n \t\t\texit(0);\n \t\t}\n-\t\telse if (!strcmp(arg, \"help\"))\n-\t\t\tshow_help = 1;\n-\t\telse if (!show_help)\n-\t\t\tcmd_usage(NULL, NULL);\n-\t}\n-\n-\tif (i >= argc || show_help) {\n-\t\tif (i >= argc)\n-\t\t\tcmd_usage(git_exec_path(), NULL);\n-\n-\t\tshow_man_page(argv[i]);\n+\t\tcmd_usage(NULL, NULL);\n \t}\n+\targv[0] = cmd;\n \n+\t/*\n+\t * We search for git commands in the following order:\n+\t * - git_exec_path()\n+\t * - the path of the \"git\" command if we could find it\n+\t * in $0\n+\t * - the regular PATH.\n+\t */\n+\tif (exec_path)\n+\t\tprepend_to_path(exec_path, strlen(exec_path));\n \texec_path = git_exec_path();\n \tprepend_to_path(exec_path, strlen(exec_path));\n \n-\texecv_git_cmd(argv + i);\n+\t/* See if it's an internal command */\n+\thandle_internal_command(argc, argv, envp);\n+\n+\t/* .. then try the external ones */\n+\texecv_git_cmd(argv);\n \n \tif (errno == ENOENT)\n-\t\tcmd_usage(exec_path, \"'%s' is not a git-command\", argv[i]);\n+\t\tcmd_usage(exec_path, \"'%s' is not a git-command\", cmd);\n \n \tfprintf(stderr, \"Failed to run command '%s': %s\\n\",\n \t\tgit_command, strerror(errno));\n"},{"id":"16772","messageId":"7vbqwt7m3t.fsf@assigned-by-dhcp.cox.net","threadId":"3470","inReplyTo":"Pine.LNX.4.64.0602261225500.22647@g5.osdl.org","subject":"Re: Teach the \"git\" command to handle some commands internally","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-26T23:10:14Z","receivedAt":"2006-02-26T23:10:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> This also implies that to support the old \"git-log\" and \"git-diff\" syntax, \n> the \"git\" wrapper now automatically looks at the name it was executed as, \n> and if it is \"git-xxxx\", it will assume that it is to internally do what \n> \"git xxxx\" would do.\n>\n> In other words, you can (once you implement an internal command) soft- or \n> hard-link that command to the \"git\" wrapper command, and it will do the \n> right thing, whether you use the \"git xxxx\" or the \"git-xxxx\" format.\n\nI like this careful backward compatibility part.\n\n> There's one other change: the search order for external programs is \n> modified slightly, so that the first entry remains GIT_EXEC_DIR, but the \n> second entry is the same directory as the git wrapper itself was executed \n> out of - if we can figure it out from argv[0], of course.\n\nI am not sure about this part, though.\n"},{"id":"16774","messageId":"Pine.LNX.4.64.0602261518110.22647@g5.osdl.org","threadId":"3470","inReplyTo":"7vbqwt7m3t.fsf@assigned-by-dhcp.cox.net","subject":"Re: Teach the \"git\" command to handle some commands internally","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-26T23:22:42Z","receivedAt":"2006-02-26T23:22:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 26 Feb 2006, Junio C Hamano wrote:\n> \n> > There's one other change: the search order for external programs is \n> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the \n> > second entry is the same directory as the git wrapper itself was executed \n> > out of - if we can figure it out from argv[0], of course.\n> \n> I am not sure about this part, though.\n\nWell, what it means is that _if_ you install all your \"git\" binaries in \nsome directory that is not in your patch and is not GIT_EXEC_DIR, they \nwill still magically work, assuming you don't do something strange.\n\nIOW, you can do things like\n\n\talias git=/opt/my-git/git\n\nand all the \"git\" commands will automatically work fine, even if you \ndidn't know at compile time where you would install them, and you didn't \nset GIT_EXEC_DIR at run-time. It will still first look in GIT_EXEC_DIR, \nbut if that fails, it will take the git commands from /opt/my-git/ instead \nof from /usr/bin or whatever.\n\nIt seemed a nice thing to try to make the git wrapper execute whatever git \nversion it was installed with, rather than depend on PATH.\n\nBut hey, it's only a couple of lines out of the whole thing, so you can \ncertainly skip it (remove the\n\n\tif (exec_path)\n\t\tprepend_path(exec_path)\n\nlines to disable it).\n\n\t\tLinus\n"},{"id":"16776","messageId":"7vy7zx65v0.fsf@assigned-by-dhcp.cox.net","threadId":"3470","inReplyTo":"Pine.LNX.4.64.0602261518110.22647@g5.osdl.org","subject":"Re: Teach the \"git\" command to handle some commands internally","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-26T23:46:27Z","receivedAt":"2006-02-26T23:46:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 26 Feb 2006, Junio C Hamano wrote:\n>> \n>> > There's one other change: the search order for external programs is \n>> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the \n>> > second entry is the same directory as the git wrapper itself was executed \n>> > out of - if we can figure it out from argv[0], of course.\n>> \n>> I am not sure about this part, though.\n>\n> Well, what it means is that _if_ you install all your \"git\" binaries in \n> some directory that is not in your patch and is not GIT_EXEC_DIR, they \n> will still magically work, assuming you don't do something strange.\n\nI understood that part. I was wondering if this change defeats\nwhat Michal (you sensibly CC'ed your message to) wanted to do\nearlier, going great length trying to avoid mucking with PATH\nand \"where-ever git itself is found\" in the last round. After\nreviewing the change in 77cb17 commit, I realize my worry was\nunfounded.\n"},{"id":"16811","messageId":"1141045198.19983.9.camel@brick.watson.ibm.com","threadId":"3470","inReplyTo":"7vy7zx65v0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Teach the \"git\" command to handle some commands internally","fromName":"Michal Ostrowski","fromEmail":"mostrows@watson.ibm.com","sentAt":"2006-02-27T12:59:58Z","receivedAt":"2006-02-27T12:59:58Z","isPatch":false,"sender":{"key":"mostrows@watson.ibm.com","avatar":null},"body":"On Sun, 2006-02-26 at 15:46 -0800, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n> > On Sun, 26 Feb 2006, Junio C Hamano wrote:\n> >> \n> >> > There's one other change: the search order for external programs is \n> >> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the \n> >> > second entry is the same directory as the git wrapper itself was executed \n> >> > out of - if we can figure it out from argv[0], of course.\n> >> \n> >> I am not sure about this part, though.\n> >\n> > Well, what it means is that _if_ you install all your \"git\" binaries in \n> > some directory that is not in your patch and is not GIT_EXEC_DIR, they \n> > will still magically work, assuming you don't do something strange.\n> \n> I understood that part. I was wondering if this change defeats\n> what Michal (you sensibly CC'ed your message to) wanted to do\n> earlier, going great length trying to avoid mucking with PATH\n> and \"where-ever git itself is found\" in the last round. After\n> reviewing the change in 77cb17 commit, I realize my worry was\n> unfounded.\n\nThe changes seem reasonable for now. We can't avoid mucking with PATH\nas long as we are going to be running shell scripts that depend on PATH\nto invoke \"git-xxx\" or even \"git xxx\". I don't seen any easy solution\nto this that would not involve changing every script (albeit\nmechanically) and would not be prone to lapses in discipline.\n\nAny solution to this original problem (i.e. a special \"PATH\" for \"git*\")\nwould seem to be applicable to the behavior this patch introduces.\n\n\n-- \nMichal Ostrowski \n"}]}