|
|
|
#include <stdio.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <dirent.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <limits.h>
|
|
|
|
#include <stdarg.h>
|
|
|
|
#include "git-compat-util.h"
|
|
|
|
#include "exec_cmd.h"
|
|
|
|
#include "cache.h"
|
|
|
|
|
|
|
|
#include "builtin.h"
|
|
|
|
|
|
|
|
static void prepend_to_path(const char *dir, int len)
|
|
|
|
{
|
|
|
|
const char *old_path = getenv("PATH");
|
|
|
|
char *path;
|
|
|
|
int path_len = len;
|
|
|
|
|
|
|
|
if (!old_path)
|
|
|
|
old_path = "/usr/local/bin:/usr/bin:/bin";
|
|
|
|
|
|
|
|
path_len = len + strlen(old_path) + 1;
|
|
|
|
|
|
|
|
path = malloc(path_len + 1);
|
|
|
|
|
|
|
|
memcpy(path, dir, len);
|
|
|
|
path[len] = ':';
|
|
|
|
memcpy(path + len + 1, old_path, path_len - len);
|
|
|
|
|
|
|
|
setenv("PATH", path, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *alias_command;
|
|
|
|
static char *alias_string = NULL;
|
|
|
|
|
|
|
|
static int git_alias_config(const char *var, const char *value)
|
|
|
|
{
|
|
|
|
if (!strncmp(var, "alias.", 6) && !strcmp(var + 6, alias_command)) {
|
|
|
|
alias_string = strdup(value);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int split_cmdline(char *cmdline, const char ***argv)
|
|
|
|
{
|
|
|
|
int src, dst, count = 0, size = 16;
|
|
|
|
char quoted = 0;
|
|
|
|
|
|
|
|
*argv = malloc(sizeof(char*) * size);
|
|
|
|
|
|
|
|
/* split alias_string */
|
|
|
|
(*argv)[count++] = cmdline;
|
|
|
|
for (src = dst = 0; cmdline[src];) {
|
|
|
|
char c = cmdline[src];
|
|
|
|
if (!quoted && isspace(c)) {
|
|
|
|
cmdline[dst++] = 0;
|
|
|
|
while (cmdline[++src]
|
|
|
|
&& isspace(cmdline[src]))
|
|
|
|
; /* skip */
|
|
|
|
if (count >= size) {
|
|
|
|
size += 16;
|
|
|
|
*argv = realloc(*argv, sizeof(char*) * size);
|
|
|
|
}
|
|
|
|
(*argv)[count++] = cmdline + dst;
|
|
|
|
} else if(!quoted && (c == '\'' || c == '"')) {
|
|
|
|
quoted = c;
|
|
|
|
src++;
|
|
|
|
} else if (c == quoted) {
|
|
|
|
quoted = 0;
|
|
|
|
src++;
|
|
|
|
} else {
|
|
|
|
if (c == '\\' && quoted != '\'') {
|
|
|
|
src++;
|
|
|
|
c = cmdline[src];
|
|
|
|
if (!c) {
|
|
|
|
free(*argv);
|
|
|
|
*argv = NULL;
|
|
|
|
return error("cmdline ends with \\");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
cmdline[dst++] = c;
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cmdline[dst] = 0;
|
|
|
|
|
|
|
|
if (quoted) {
|
|
|
|
free(*argv);
|
|
|
|
*argv = NULL;
|
|
|
|
return error("unclosed quote");
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int handle_alias(int *argcp, const char ***argv)
|
|
|
|
{
|
|
|
|
int nongit = 0, ret = 0, saved_errno = errno;
|
|
|
|
const char *subdir;
|
|
|
|
|
|
|
|
subdir = setup_git_directory_gently(&nongit);
|
|
|
|
if (!nongit) {
|
|
|
|
int count;
|
|
|
|
const char** new_argv;
|
|
|
|
|
|
|
|
alias_command = (*argv)[0];
|
|
|
|
git_config(git_alias_config);
|
|
|
|
if (alias_string) {
|
|
|
|
|
|
|
|
count = split_cmdline(alias_string, &new_argv);
|
|
|
|
|
|
|
|
if (count < 1)
|
|
|
|
die("empty alias for %s", alias_command);
|
|
|
|
|
|
|
|
if (!strcmp(alias_command, new_argv[0]))
|
|
|
|
die("recursive alias: %s", alias_command);
|
|
|
|
|
|
|
|
/* insert after command name */
|
|
|
|
if (*argcp > 1) {
|
|
|
|
new_argv = realloc(new_argv, sizeof(char*) *
|
|
|
|
(count + *argcp));
|
|
|
|
memcpy(new_argv + count, *argv + 1,
|
|
|
|
sizeof(char*) * *argcp);
|
|
|
|
}
|
|
|
|
|
|
|
|
*argv = new_argv;
|
|
|
|
*argcp += count - 1;
|
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (subdir)
|
|
|
|
chdir(subdir);
|
|
|
|
|
|
|
|
errno = saved_errno;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char git_version_string[] = GIT_VERSION;
|
|
|
|
|
|
|
|
static void handle_internal_command(int argc, const char **argv, char **envp)
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
{
|
|
|
|
const char *cmd = argv[0];
|
|
|
|
static struct cmd_struct {
|
|
|
|
const char *cmd;
|
|
|
|
int (*fn)(int, const char **, char **);
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
} commands[] = {
|
|
|
|
{ "version", cmd_version },
|
|
|
|
{ "help", cmd_help },
|
|
|
|
{ "log", cmd_log },
|
|
|
|
{ "whatchanged", cmd_whatchanged },
|
|
|
|
{ "show", cmd_show },
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
{ "push", cmd_push },
|
|
|
|
{ "format-patch", cmd_format_patch },
|
|
|
|
{ "count-objects", cmd_count_objects },
|
|
|
|
{ "diff", cmd_diff },
|
|
|
|
{ "grep", cmd_grep },
|
Add builtin "git rm" command
This changes semantics very subtly, because it adds a new atomicity
guarantee.
In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.
This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.
So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.
This is only an issue with "-f", of course.
I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).
The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
{ "rm", cmd_rm },
|
|
|
|
{ "add", cmd_add },
|
|
|
|
{ "rev-list", cmd_rev_list },
|
|
|
|
{ "init-db", cmd_init_db },
|
|
|
|
{ "get-tar-commit-id", cmd_get_tar_commit_id },
|
|
|
|
{ "upload-tar", cmd_upload_tar },
|
|
|
|
{ "check-ref-format", cmd_check_ref_format },
|
|
|
|
{ "ls-files", cmd_ls_files },
|
|
|
|
{ "ls-tree", cmd_ls_tree },
|
|
|
|
{ "tar-tree", cmd_tar_tree },
|
|
|
|
{ "read-tree", cmd_read_tree },
|
|
|
|
{ "commit-tree", cmd_commit_tree },
|
|
|
|
{ "apply", cmd_apply },
|
|
|
|
{ "show-branch", cmd_show_branch },
|
|
|
|
{ "diff-files", cmd_diff_files },
|
|
|
|
{ "diff-index", cmd_diff_index },
|
|
|
|
{ "diff-stages", cmd_diff_stages },
|
|
|
|
{ "diff-tree", cmd_diff_tree },
|
|
|
|
{ "cat-file", cmd_cat_file },
|
|
|
|
{ "rev-parse", cmd_rev_parse },
|
|
|
|
{ "write-tree", cmd_write_tree },
|
|
|
|
{ "mailsplit", cmd_mailsplit },
|
|
|
|
{ "mailinfo", cmd_mailinfo },
|
|
|
|
{ "stripspace", cmd_stripspace },
|
|
|
|
{ "update-index", cmd_update_index },
|
|
|
|
{ "update-ref", cmd_update_ref },
|
|
|
|
{ "fmt-merge-msg", cmd_fmt_merge_msg }
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
};
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Turn "git cmd --help" into "git help cmd" */
|
|
|
|
if (argc > 1 && !strcmp(argv[1], "--help")) {
|
|
|
|
argv[1] = argv[0];
|
|
|
|
argv[0] = cmd = "help";
|
|
|
|
}
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
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, const char **argv, char **envp)
|
|
|
|
{
|
|
|
|
const char *cmd = argv[0];
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
char *slash = strrchr(cmd, '/');
|
|
|
|
const char *exec_path = NULL;
|
|
|
|
int done_alias = 0;
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
/*
|
|
|
|
* "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);
|
|
|
|
}
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
/* Default command: "help" */
|
|
|
|
cmd = "help";
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
/* Look for flags.. */
|
|
|
|
while (argc > 1) {
|
|
|
|
cmd = *++argv;
|
|
|
|
argc--;
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
if (strncmp(cmd, "--", 2))
|
|
|
|
break;
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
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;
|
|
|
|
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
puts(git_exec_path());
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
cmd_usage(0, NULL, NULL);
|
|
|
|
}
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
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));
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
/* See if it's an internal command */
|
|
|
|
handle_internal_command(argc, argv, envp);
|
|
|
|
|
|
|
|
/* .. then try the external ones */
|
|
|
|
execv_git_cmd(argv);
|
Teach the "git" command to handle some commands internally
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
|
|
|
|
/* It could be an alias -- this works around the insanity
|
|
|
|
* of overriding "git log" with "git show" by having
|
|
|
|
* alias.log = show
|
|
|
|
*/
|
|
|
|
if (done_alias || !handle_alias(&argc, &argv))
|
|
|
|
break;
|
|
|
|
done_alias = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (errno == ENOENT)
|
|
|
|
cmd_usage(0, exec_path, "'%s' is not a git-command", cmd);
|
|
|
|
|
|
|
|
fprintf(stderr, "Failed to run command '%s': %s\n",
|
|
|
|
cmd, strerror(errno));
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|