aboutsummaryrefslogtreecommitdiff
path: root/builtin/rev-list.c
Commit message (Collapse)AuthorAge
* rev-list --verify-objectJunio C Hamano2011-09-01
| | | | | | | | | | | | | | | | | Often we want to verify everything reachable from a given set of commits are present in our repository and connected without a gap to the tips of our refs. We used to do this for this purpose: $ rev-list --objects $commits_to_be_tested --not --all Even though this is good enough for catching missing commits and trees, we show the object name but do not verify their existence, let alone their well-formedness, for the blob objects at the leaf level. Add a new "--verify-object" option so that we can catch missing and broken blobs as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* list-objects: pass callback data to show_objects()Junio C Hamano2011-09-01
| | | | | | | | | | | The traverse_commit_list() API takes two callback functions, one to show commit objects, and the other to show other kinds of objects. Even though the former has a callback data parameter, so that the callback does not have to rely on global state, the latter does not. Give the show_objects() callback the same callback data parameter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* revision.c: add show_object_with_name() helper functionJunio C Hamano2011-08-22
| | | | | | | | | | There are two copies of traverse_commit_list callback that show the object name followed by pathname the object was found, to produce output similar to "rev-list --objects". Unify them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: fix finish_object() callJunio C Hamano2011-08-22
| | | | | | | | | | | The callback to traverse_commit_list() are to take linked name_path and a string for the last path component. If the callee used its parameters, it would have seen duplicated leading paths. In this particular case, the callee does not use this argument but that is not a reason to leave the call broken. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/format-patch-am'Junio C Hamano2011-05-31
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/format-patch-am: format-patch: preserve subject newlines with -k clean up calling conventions for pretty.c functions pretty: add pp_commit_easy function for simple callers mailinfo: always clean up rfc822 header folding t: test subject handling in format-patch / am pipeline Conflicts: builtin/branch.c builtin/log.c commit.h
| * clean up calling conventions for pretty.c functionsJeff King2011-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a pretty_print_context representing the parameters for a pretty-print session, but we did not use it uniformly. As a result, functions kept growing more and more arguments. Let's clean this up in a few ways: 1. All pretty-print pp_* functions now take a context. This lets us reduce the number of arguments to these functions, since we were just passing around the context values separately. 2. The context argument now has a cmit_fmt field, which was passed around separately. That's one less argument per function. 3. The context argument always comes first, which makes calling a little more uniform. This drops lines from some callers, and adds lines in a few places (because we need an extra line to set the context's fmt field). Overall, we don't save many lines, but the lines that are there are a lot simpler and more readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list --count: separate count for --cherry-markMichael J Gruber2011-04-26
| | | | | | | | | | | | | | | | | | When --count is used with --cherry-mark, omit the patch equivalent commits from the count for left and right commits and print the count of equivalent commits separately. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | revision.c: introduce --min-parents and --max-parents optionsMichael J Gruber2011-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce --min-parents and --max-parents options which limit the revisions to those commits which have at least (or at most) that many commits, where negative arguments for --max-parents= denote infinity (i.e. no upper limit). In particular: --max-parents=1 is the same as --no-merges; --min-parents=2 is the same as --merges; --max-parents=0 shows only roots; and --min-parents=3 shows only octopus merges Using --min-parents=n and --max-parents=m with n>m gives you what you ask for (i.e. nothing) for obvious reasons, just like when you give --merges (show only merge commits) and --no-merges (show only non-merge commits) at the same time. Also, introduce --no-min-parents and --no-max-parents to do the obvious thing for convenience. We compute the number of parents only when we limit by that, so there is no performance impact when there are no limiters. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list/log: factor out revision mark generationMichael J Gruber2011-03-09
|/ | | | | | | | | | | | | | Currently, we have identical code for generating revision marks ('<', '>', '-') in 5 places. Factor out the code to a single function get_revision_mark() for easier maintenance and extensibility. Note that the check for !!revs in graph.c (which gets removed effectively by this patch) is superfluous. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/maint-rev-list-nul'Junio C Hamano2010-11-17
|\ | | | | | | | | * jk/maint-rev-list-nul: rev-list: handle %x00 NUL in user format
| * rev-list: handle %x00 NUL in user formatJeff King2010-10-13
| | | | | | | | | | | | | | | | | | | | | | | | The code paths for showing commits in "git log" and "git rev-list --graph" correctly handle embedded NULs by looking only at the resulting strbuf's length, and never treating it as a C string. The code path for regular rev-list, however, used printf("%s"), which resulted in truncated output. This patch uses fwrite instead, like the --graph code path. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Use angles for placeholders consistentlyŠtěpán Němec2010-10-08
|/ | | | | | Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: introduce --count optionThomas Rast2010-06-12
| | | | | | | | | | | | | | Add a --count option that, instead of actually listing the commits, merely counts them. This is mostly geared towards script use, and to this end it acts specially when used with --left-right: it outputs the left and right counts separately. Previously, scripts would have to run a shell loop or small inline script over to achieve the same. (Without --left-right, a simple |wc -l does the job.) Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ef/maint-empty-commit-log'Junio C Hamano2010-04-06
| | | | | * ef/maint-empty-commit-log: rev-list: fix --pretty=oneline with empty message
* Merge branch 'mg/use-default-abbrev-length-in-rev-list'Junio C Hamano2010-04-03
| | | | | * mg/use-default-abbrev-length-in-rev-list: rev-list: use default abbrev length when abbrev-commit is in effect
* Merge branch 'lt/deepen-builtin-source'Junio C Hamano2010-03-10
| | | | | | | | * lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
* Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds2010-02-22
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>