kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Rene Scharfe	ec26b4d6b0	Fix sparse warnings about non-ANSI function prototypes Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	7b0c996679	Move "--parent" parsing into generic revision.c library code Not only do we do it in both rev-list.c and git.c, the revision walking code will soon want to know whether we should rewrite parenthood information or not. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Fredrik Kuivinen	a87cd02ce0	Nicer output from 'git' [jc: with suggestions by Jan-Benedict Glaw] Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	b4f2a6ac92	Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0])) Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	9201c70742	Const tightening. Mark Wooding noticed there was a type mismatch warning in git.c; this patch does things slightly differently (mostly tightening const) and was what I was holding onto, waiting for the setup-revisions change to be merged into the master branch. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	64bc6e3db5	setup_revisions(): handle -n<n> and -<n> internally. This moves the handling of max-count shorthand from the internal implementation of "git log" to setup_revisions() so other users of setup_revisions() can use it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	7ae0b0cb65	git-log (internal): more options. This ports the following options from rev-list based git-log implementation: * -<n>, -n<n>, and -n <n>. I am still wondering if we want this natively supported by setup_revisions(), which already takes --max-count. We may want to move them in the next round. Also I am not sure if we can get away with not setting revs->limited when we set max-count. The latest rev-list.c and revision.c in this series do not, so I left them as they are. * --pretty and --pretty=<fmt>. * --abbrev=<n> and --no-abbrev. The previous commit already handles time-based limiters (--since, --until and friends). The remaining things that rev-list based git-log happens to do are not useful in a pure log-viewing purposes, and not ported: * --bisect (obviously). * --header. I am actually in favor of doing the NUL terminated record format, but rev-list based one always passed --pretty, which defeated this option. Maybe next round. * --parents. I do not think of a reason a log viewer wants this. The flag is primarily for feeding squashed history via pipe to downstream tools. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	70b006b971	Tie it all together: "git log" This is what the previous diffs all built up to. We can do "git log" as a trivial small helper function inside git.c, because the infrastructure is all there for us to use as a library. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	231af8322a	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
Michal Ostrowski	77cb17e940	Exec git programs without using PATH. 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 wrapper will modify PATH as before to enable shell scripts to invoke "git-foo" commands. Ideally, shell scripts should use the git wrapper to become independent of PATH, and then modifying PATH will not be necessary. [jc: with minor updates after a brief review.] Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Andreas Ericsson	da6bf70ebf	git: grok 'help' to mean '--help'. Most other scm's understand it, most users expect it and it's an easy fix. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Alex Riesen	7246ed438c	\n usage in stderr output fprintf and die sometimes have missing/excessive "\n" in their arguments, correct the strings where I think it would be appropriate. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	112d0bafd6	Make "git help" sort git commands in columns This changes "pretty_print_string_list()" to show the git commands alphabetically in column order, which is the normal one. Ie instead of doing git commands available in '/home/torvalds/bin' ---------------------------------------------- add am ... applypatch archimport ... cat-file check-ref-format ... ... it does git commands available in '/home/torvalds/bin' ---------------------------------------------- add diff-tree ... am fetch ... apply fetch-pack ... ... where each column is sorted. This is how "ls" sorts things too, and since visually the columns are much more distinct than the rows, so it _looks_ more sorted. The "ls" command has a "-x" option that lists entries by lines (the way git.c used to): if somebody wants to do that, the new print-out logic could be easily accomodated to that too. Matter of taste and preference, I guess. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	ea77e675e5	Make "git help" react to window size correctly Currently the git "show commands" function will react to the environment variable COLUMNS, or just default to a width of 80 characters. That's just soo eighties. Nobody sane sets COLUMNS any more, unless they need to support some stone-age software from before the age of steam engines, SIGWINCH and TIOCGWINSZ. So get with the new century, and use TIOCGWINSZ to get the terminal size. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	4050c0df8e	Clean up compatibility definitions. This attempts to clean up the way various compatibility functions are defined and used. - A new header file, git-compat-util.h, is introduced. This looks at various NO_XXX and does necessary function name replacements, equivalent of -Dstrcasestr=gitstrcasestr in the Makefile. - Those function name replacements are removed from the Makefile. - Common features such as usage(), die(), xmalloc() are moved from cache.h to git-compat-util.h; cache.h includes git-compat-util.h itself. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	b270c634b7	git.c: remove excess output for debugging when command is too long. When the given command name was too long, we exited with a message with the number of bytes of the final command name inside parentheses, without saying what that number is. It was only meant as a debugging aid while development, so remove it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	9a79c5a8b4	git.c: two fixes, gitsetenv type and off-by-one error. gitsetenv as implemented in compat/setenv.c takes two const char* and int; match that. Also fix an incorrect attempt in prepend_to_path() to NUL-terminate the string which stuffed the NUL character at one past the end of allocation, and was not needed to begin with (we copy the old_path string including the NUL which terminates it). Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Jason Riedy	e40b61fb6b	Add compat/setenv.c, use in git.c. There is no setenv() in Solaris 5.8. The trivial calls to setenv() were replaced by putenv() in a much earlier patch, but setenv() was used again in git.c. This patch just adds a compat/setenv.c. The rule for building git$(X) also needs to include compat. objects and compiler flags. Those are now in makefile vars COMPAT_OBJS and COMPAT_CFLAGS. Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Alex Riesen	10b15b86f5	git wrapper: more careful argument stuffing - Use stderr for error output - Build git_command more careful - ENOENT is good enough for check of failed exec to show usage, no access() check needed [jc: Originally from Alex Riesen with inputs from Sven Verdoolaege mixed in.] Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
YOSHIFUJI Hideaki / 吉藤英明	874fbc3323	Fix a warning about unused value. Fix a warning: git.c:276: warning: value computed is not used Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	f9039f30d5	Do not show .exe in git command list. Truncate the result from readdir() in the exec-path if they end with .exe, to make it a bit more readable on Cygwin. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	27dedf0c3b	GIT 0.99.9j aka 1.0rc3 Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	7dbc2c0402	git wrapper: basic fixes. Updates to fix the nits found during the list discussion. - Lose PATH_TO_MAN; just rely on execlp() to find whereever the "man" command is installed. - Do not randomly chdir(), but concatenate to the current working directory only if the given path is not absolute. - Lose use of glob(); read from exec_path and do sorting ourselves -- it is not that much more work. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Andreas Ericsson	97fc6c5fba	git --help COMMAND brings up the git-COMMAND man-page. It's by design a bit stupid (matching ^git rather than ^git-), so as to work with 'gitk' and 'git' as well. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Andreas Ericsson	8e49d50388	C implementation of the 'git' program, take two. This patch provides a C implementation of the 'git' program and introduces support for putting the git-* commands in a directory of their own. It also saves some time on executing those commands in a tight loop and it prints the currently available git commands in a nicely formatted list. The location of the GIT_EXEC_PATH (name discussion's closed, thank gods) can be obtained by running git --exec-path which will hopefully give porcelainistas ample time to adapt their heavy-duty loops to call the core programs directly and thus save the extra fork() / execve() overhead, although that's not really necessary any more. The --exec-path value is prepended to $PATH, so the git-* programs should Just Work without ever requiring any changes to how they call other programs in the suite. Some timing values for 10000 invocations of git-var >&/dev/null: git.sh: 24.194s git.c: 9.044s git-var: 7.377s The git-<tab><tab> behaviour can, along with the someday-to-be-deprecated git-<command> form of invocation, be indefinitely retained by adding the following line to one's .bash_profile or equivalent: PATH=$PATH:$(git --exec-path) Experimental libraries can be used by either setting the environment variable GIT_EXEC_PATH, or by using git --exec-path=/some/experimental/exec-path Relative paths are properly grok'ed as exec-path values. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

1 2

84 Commits (7a9b4c5fe3b8d291063c398ecb655281a60b2be7)