path: root/git.c
AgeCommit message (Collapse)Author
2006-04-16Support "git cmd --help" syntaxLinus Torvalds
The "--help" argument is special, in that it is (along with "--version") in that is taken by the "git" program itself rather than the sub-command, and thus we've had the syntax "git --help cmd". However, as anybody who has ever used CVS or some similar devil-spawn program, it's confusing as h*ll when options before the sub-command act differently from options after the sub-command, so this quick hack just makes it acceptable to do "git cmd --help" instead, and get the exact same result. It may be hacky, but it's simple and does the trick. Of course, this does not help if you use one of the non-builtin commands without using the "git" helper. Ie you won't be getting a man-page just because you do "git-rev-list --help". Don't expect us to be quite _that_ helpful. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-04-15diff --stat: do not do its own three-dashes.Junio C Hamano
I missed that "git-diff-* --stat" spits out three-dash separator on its own without being asked. Remove it. When we output commit log followed by diff, perhaps --patch-with-stat, for downstream consumer, we _would_ want the three-dash between the message and the diff material, but that logic belongs to the caller, not diff generator. Signed-off-by: Junio C Hamano <>
2006-04-15Fix up default abbrev in setup_revisions() argument parser.Junio C Hamano
The default abbreviation precision should be DEFAULT_ABBREV as before. Signed-off-by: Junio C Hamano <>
2006-04-15Common option parsing for "git log --diff" and friendsLinus Torvalds
This basically does a few things that are sadly somewhat interdependent, and nontrivial to split out - get rid of "struct log_tree_opt" The fields in "log_tree_opt" are moved into "struct rev_info", and all users of log_tree_opt are changed to use the rev_info struct instead. - add the parsing for the log_tree_opt arguments to "setup_revision()" - make setup_revision set a flag (revs->diff) if the diff-related arguments were used. This allows "git log" to decide whether it wants to show diffs or not. - make setup_revision() also initialize the diffopt part of rev_info (which we had from before, but we just didn't initialize it) - make setup_revision() do all the "finishing touches" on it all (it will do the proper flag combination logic, and call "diff_setup_done()") Now, that was the easy and straightforward part. The slightly more involved part is that some of the programs that want to use the new-and-improved rev_info parsing don't actually want _commits_, they may want tree'ish arguments instead. That meant that I had to change setup_revision() to parse the arguments not into the "revs->commits" list, but into the "revs->pending_objects" list. Then, when we do "prepare_revision_walk()", we walk that list, and create the sorted commit list from there. This actually cleaned some stuff up, but it's the less obvious part of the patch, and re-organized the "revision.c" logic somewhat. It actually paves the way for splitting argument parsing _entirely_ out of "revision.c", since now the argument parsing really is totally independent of the commit walking: that didn't use to be true, since there was lots of overlap with get_commit_reference() handling etc, now the _only_ overlap is the shared (and trivial) "add_pending_object()" thing. However, I didn't do that file split, just because I wanted the diff itself to be smaller, and show the actual changes more clearly. If this gets accepted, I'll do further cleanups then - that includes the file split, but also using the new infrastructure to do a nicer "git diff" etc. Even in this form, it actually ends up removing more lines than it adds. It's nice to note how simple and straightforward this makes the built-in "git log" command, even though it continues to support all the diff flags too. It doesn't get much simpler that this. I think this is worth merging soonish, because it does allow for future cleanup and even more sharing of code. However, it obviously touches "revision.c", which is subtle. I've tested that it passes all the tests we have, and it passes my "looks sane" detector, but somebody else should also give it a good look-over. [jc: squashed the original and three "oops this too" updates, with another fix-up.] Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-04-13Use less memory in "git log"Linus Torvalds
This trivially avoids keeping the commit message data around after we don't need it any more, avoiding a continually growing "git log" memory footprint. It's not a huge deal, but it's somewhat noticeable. For the current kernel tree, doing a full "git log" I got - before: /usr/bin/time git log > /dev/null 0.81user 0.02system 0:00.84elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+8851minor)pagefaults 0swaps - after: /usr/bin/time git log > /dev/null 0.79user 0.03system 0:00.83elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5039minor)pagefaults 0swaps ie the touched pages dropped from 8851 to 5039. For the historic kernel archive, the numbers are 18357->11037 minor page faults. We could/should in theory free the commits themselves, but that's really a lot harder, since during revision traversal we may hit the same commit twice through different children having it as a parent, even after we've shown it once (when that happens, we'll silently ignore it next time, but we still need the "struct commit" to know). And as the commit message data is clearly the biggest part of the commit, this is the really easy 60% solution. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-04-13git-log: do not output excess blank line between commitsJunio C Hamano
Signed-off-by: Junio C Hamano <>
2006-04-11blame and friends: adjust to multiple pathspec change.Junio C Hamano
This makes things that include revision.h build again. Blame is also built, but I am not sure how well it works (or how well it worked to begin with) -- it was relying on tree-diff to be using whatever pathspec was used the last time, which smells a bit suspicious. Signed-off-by: Junio C Hamano <>
2006-04-10git log --full-diffJunio C Hamano
Without this flag, "git log -p paths..." shows commits that touch the specified paths, and diffs about the same specified paths. With this, the full diff is shown for commits that touch the specified paths. Signed-off-by: Junio C Hamano <>
2006-04-09git log [diff-tree options]...Junio C Hamano
And this makes "git log" to take common diff-tree options, so that it can be used as "git whatchanged". The recent revision walker updates by Linus to make path limiting low-latency helps this quite a bit. Signed-off-by: Junio C Hamano <>
2006-04-09git-log: match rev-list --abbrev and --abbrev-commitJunio C Hamano
Signed-off-by: Junio C Hamano <>
2006-04-02Fix sparse warnings about non-ANSI function prototypesRene Scharfe
Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2006-04-01Move "--parent" parsing into generic revision.c library codeLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2006-03-09Nicer output from 'git'Fredrik Kuivinen
[jc: with suggestions by Jan-Benedict Glaw] Signed-off-by: Fredrik Kuivinen <> Signed-off-by: Junio C Hamano <>
2006-03-09Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-03-05Const tightening.Junio C Hamano
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 <>
2006-03-02setup_revisions(): handle -n<n> and -<n> internally.Junio C Hamano
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 <>
2006-03-01git-log (internal): more options.Junio C Hamano
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 <>
2006-02-28Tie it all together: "git log"Linus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2006-02-26Teach the "git" command to handle some commands internallyLinus 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 <> Signed-off-by: Junio C Hamano <>
2006-01-14Exec git programs without using PATH.Michal Ostrowski
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 <> Signed-off-by: Junio C Hamano <>
2006-01-06git: grok 'help' to mean '--help'.Andreas Ericsson
Most other scm's understand it, most users expect it and it's an easy fix. Signed-off-by: Andreas Ericsson <> Signed-off-by: Junio C Hamano <>
2005-12-22\n usage in stderr outputAlex Riesen
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 <> Signed-off-by: Junio C Hamano <>
2005-12-18Make "git help" sort git commands in columnsLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-12-18Make "git help" react to window size correctlyLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-12-05Clean up compatibility definitions.Junio C Hamano
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 <>
2005-12-05git.c: remove excess output for debugging when command is too long.Junio C Hamano
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 <>
2005-12-04git.c: two fixes, gitsetenv type and off-by-one error.Junio C Hamano
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 <>
2005-12-04Add compat/setenv.c, use in git.c.Jason Riedy
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 <> Signed-off-by: Junio C Hamano <>
2005-12-02git wrapper: more careful argument stuffingAlex Riesen
- 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 <>
2005-11-25Fix a warning about unused value.YOSHIFUJI Hideaki / 吉藤英明
Fix a warning: git.c:276: warning: value computed is not used Signed-off-by: YOSHIFUJI Hideaki <> Signed-off-by: Junio C Hamano <>
2005-11-18Do not show .exe in git command list.Junio C Hamano
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 <>
2005-11-16git wrapper: basic fixes.Junio C Hamano
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 <>
2005-11-16git --help COMMAND brings up the git-COMMAND man-page.Andreas Ericsson
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 <> Signed-off-by: Junio C Hamano <>
2005-11-16C implementation of the 'git' program, take two.Andreas Ericsson
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: 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 <> Signed-off-by: Junio C Hamano <>