aboutsummaryrefslogtreecommitdiff
path: root/builtin-rev-list.c
Commit message (Collapse)AuthorAge
* bisect: add parameters to "filter_skipped"Christian Couder2009-06-06
| | | | | | | | | | | | | | | | | | | | | | | | because we will need to get more information from this function in some later patches. The new "int *count" parameter gives the number of commits left after the skipped commit have been filtered out. The new "int *skipped_first" parameter tells us if the first commit in the list has been skipped. Note that using this parameter also changes the behavior of the function if the first commit is indeed skipped. Because we assume that in this case we will want all the filtered commits, not just the first one, even if "show_all" is not set. So using a not NULL "skipped_first" parameter really means that we plan to choose to test another commit than the first non skipped one if the first commit in the list is skipped. That in turn means that, in case the first commit is skipped, we have to return a fully filtered list. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: remove stringed output flag from "show_bisect_vars"Christian Couder2009-05-10
| | | | | | | | Because it was used only by "git bisect--helper --next-vars" but the "--next-vars" option has been removed. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: refactor printing bisect varsChristian Couder2009-05-10
| | | | | | | | This simplifies the code, and while at it we create the "print_commit_list" function that will be reused later. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: make "estimate_bisect_steps" non staticChristian Couder2009-05-10
| | | | | | | Because it will be used from "bisect.c" too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'lt/pack-object-memuse'Junio C Hamano2009-04-18
|\ | | | | | | | | | | | | | | | | | | | | | | | | * lt/pack-object-memuse: show_object(): push path_name() call further down process_{tree,blob}: show objects without buffering Conflicts: builtin-pack-objects.c builtin-rev-list.c list-objects.c list-objects.h upload-pack.c
| * show_object(): push path_name() call further downLinus Torvalds2009-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, pushing the "path_name()" call _into_ the show() function would seem to allow - more clarity into who "owns" the name (ie now when we free the name in the show_object callback, it's because we generated it ourselves by calling path_name()) - not calling path_name() at all, either because we don't care about the name in the first place, or because we are actually happy walking the linked list of "struct name_path *" and the last component. Now, I didn't do that latter optimization, because it would require some more coding, but especially looking at "builtin-pack-objects.c", we really don't even want the whole pathname, we really would be better off with the list of path components. Why? We use that name for two things: - add_preferred_base_object(), which actually _wants_ to traverse the path, and now does it by looking for '/' characters! - for 'name_hash()', which only cares about the last 16 characters of a name, so again, generating the full name seems to be just unnecessary work. Anyway, so I didn't look any closer at those things, but it did convince me that the "show_object()" calling convention was crazy, and we're actually better off doing _less_ in list-objects.c, and giving people access to the internal data structures so that they can decide whether they want to generate a path-name or not. This patch does that, and then for people who did use the name (even if they might do something more clever in the future), it just does the straightforward "name = path_name(path, component); .. free(name);" thing. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * process_{tree,blob}: show objects without bufferingLinus Torvalds2009-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here's a less trivial thing, and slightly more dubious one. I was looking at that "struct object_array objects", and wondering why we do that. I have honestly totally forgotten. Why not just call the "show()" function as we encounter the objects? Rather than add the objects to the object_array, and then at the very end going through the array and doing a 'show' on all, just do things more incrementally. Now, there are possible downsides to this: - the "buffer using object_array" _can_ in theory result in at least better I-cache usage (two tight loops rather than one more spread out one). I don't think this is a real issue, but in theory.. - this _does_ change the order of the objects printed. Instead of doing a "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop over the commits (which puts all the root trees _first_ in the object list, this patch just adds them to the list of pending objects, and then we'll traverse them in that order (and thus show each root tree object together with the objects we discover under it) I _think_ the new ordering actually makes more sense, but the object ordering is actually a subtle thing when it comes to packing efficiency, so any change in order is going to have implications for packing. Good or bad, I dunno. - There may be some reason why we did it that odd way with the object array, that I have simply forgotten. Anyway, now that we don't buffer up the objects before showing them that may actually result in lower memory usage during that whole traverse_commit_list() phase. This is seriously not very deeply tested. It makes sense to me, it seems to pass all the tests, it looks ok, but... Does anybody remember why we did that "object_array" thing? It used to be an "object_list" a long long time ago, but got changed into the array due to better memory usage patterns (those linked lists of obejcts are horrible from a memory allocation standpoint). But I wonder why we didn't do this back then. Maybe there's a reason for it. Or maybe there _used_ to be a reason, and no longer is. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: add "int bisect_show_flags" in "struct rev_list_info"Christian Couder2009-04-07
| | | | | | | | | | | | | | | | | | This is a cleanup patch to make it easier to use the "show_bisect_vars" function and take advantage of the rev_list_info struct. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: remove last static vars used in "show_commit"Christian Couder2009-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the last static variables that were used in the "show_commit" function. To do that, we create a new "rev_list_info" struct that we will pass in the "void *data" argument to "show_commit". This means that we have to change the first argument to "show_bisect_vars" too. While at it, we also remove a "struct commit_list *list" variable in "cmd_rev_list" that is not really needed. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | list-objects: add "void *data" parameter to show functionsChristian Couder2009-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of this patch is to get rid of the "static struct rev_info revs" static variable in "builtin-rev-list.c". To do that, we need to pass the revs to the "show_commit" function in "builtin-rev-list.c" and this in turn means that the "traverse_commit_list" function in "list-objects.c" must be passed functions pointers to functions with 2 parameters instead of one. So we have to change all the callers and all the functions passed to "traverse_commit_list". Anyway this makes the code more clean and more generic, so it should be a good thing in the long run. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | bisect--helper: string output variables together with "&&"Christian Couder2009-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing: eval "git bisect--helper --next-vars" | { while read line do echo "$line &&" done echo ':' } the result code comes from the last "echo ':'", not from running "git bisect--helper --next-vars". This patch gets rid of the need to string together the line from the output of "git bisect--helper" with "&&" in the calling script by making "git bisect--helper --next-vars" return output variables already in that format. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: pass "int flags" as last argument of "show_bisect_vars"Christian Couder2009-04-05
| | | | | | | | | | | | | | | | Instead of "int show_all, int show_tried" we now only pass "int flags", because we will add one more flag in a later patch. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: call new "filter_skip" functionChristian Couder2009-04-05
| | | | | | | | | | | | | | | | | | | | | | | | This patch implements a new "filter_skip" function in C in "bisect.c" that will later replace the existing implementation in shell in "git-bisect.sh". An array is used to store the skipped commits. But the array is not yet fed anything. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: pass "revs" to "show_bisect_vars"Christian Couder2009-03-30
| | | | | | | | | | | | | | instead of using static "revs" data Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: make "show_bisect_vars" non staticChristian Couder2009-03-30
| | | | | | | | | | | | | | | | | | | | and declare it in "bisect.h" as we will use this function later. While at it, rename its last argument "show_all" instead of "bisect_find_all". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: move code to show bisect vars into its own functionChristian Couder2009-03-30
| | | | | | | | | | | | | | | | This is a straightforward clean up to make "cmd_rev_list" function smaller. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: move bisect related code into its own fileChristian Couder2009-03-30
| | | | | | | | | | | | | | | | | | | | | | This patch creates new "bisect.c" and "bisect.h" files and move bisect related code into these files. While at it, we also remove some include directives that are not needed any more from the beginning of "builtin-rev-list.c". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: make "bisect_list" variable local to "cmd_rev_list"Christian Couder2009-03-30
| | | | | | | | | | | | | | | | The "bisect_list" variable was static for no reason as it is only used in the "cmd_rev_list" function. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: estimate number of bisection step leftChristian Couder2009-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches "git rev-list --bisect-vars" to output an estimate of the number of bisection step left _after the current one_ along with the other variables it already outputs. This patch also makes "git-bisect.sh" display this number of steps left _after the current one_, along with the estimate of the number of revisions left to test (after the current one). Here is a table to help analyse what should be the best estimate for the number of bisect steps left. N : linear case --> probabilities --> best ------------------------------------------------------------- 1 : G-B --> 0 --> 0 2 : G-U1-B --> 0 --> 0 3 : G-U1-U2-B --> 0(1/3) 1(2/3) --> 1 4 : G-U1-U2-U3-B --> 1 --> 1 5 : G-U1-U2-U3-U4-B --> 1(3/5) 2(2/5) --> 1 6 : G-U1-U2-U3-U4-U5-B --> 1(2/6) 2(4/6) --> 2 7 : G-U1-U2-U3-U4-U5-U6-B --> 1(1/7) 2(6/7) --> 2 8 : G-U1-U2-U3-U4-U5-U6-U7-B --> 2 --> 2 9 : G-U1-U2-U3-U4-U5-U6-U7-U8-B --> 2(7/9) 3(2/9) --> 2 10: G-U1-U2-U3-U4-U5-U6-U7-U8-U9-B --> 2(6/10)3(4/10)--> 2 In the column "N", there is the number of revisions that could _now_ be the first bad commit we are looking for. The "linear case" column describes the linear history corresponding to the number in column N. G means good, B means bad, and Ux means unknown. Note that the first bad revision we are looking for can be any Ux or B. In the "probabilities" column, there are the different outcomes in number of steps with the odds of each outcome in parenthesis corresponding to the linear case. The "best" column gives the most accurate estimate among the different outcomes in the "probabilities" column. We have the following: best(2^n) == n - 1 and for any x between 0 included and 2^n excluded, the probability for n - 1 steps left looks like: P(2^n + x) == (2^n - x) / (2^n + x) and P(2^n + x) < 0.5 means 2^n < 3x So the algorithm used in this patch calculates 2^n and x, and then choose between returning n - 1 and n. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: fix showing distance when using --bisect-allChristian Couder2009-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before d467a52 ("Make '--decorate' set an explicit 'show_decorations' flag", Nov 3 2008), commit decorations were shown whenever they exist, and distances stored in them by "git rev-list --bisect-all" were automatically shown. d467a52 changed the rule so that commit decorations are not shown unless rev_info explicitly asks to, with its show_decorations bit, but forgot that the ones "git rev-list --bisect-all" adds need to be shown. This patch fixes this old breakage. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add a 'source' decorator for commitsLinus Torvalds2008-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already support decorating commits by tags or branches that point to them, but especially when we are looking at multiple branches together, we sometimes want to see _how_ we reached a particular commit. We can abuse the '->util' field in the commit to keep track of that as we walk the commit lists, and get a reasonably useful view into which branch or tag first reaches that commit. Of course, if the commit is reachable through multiple sources (which is common), our particular choice of "first" reachable is entirely random and depends on the particular path we happened to follow. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerBrandon Casey2008-10-12
|/ | | | | | | | | | | Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Start conforming code to "git subcmd" style part 3Heikki Orsila2008-09-15
| | | | | | | | User notifications are presented as 'git cmd', and code comments are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'. Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix "git log -i --grep"Jeff King2008-08-24
| | | | | | | | | | | | | | | | | | | | | | This has been broken in v1.6.0 due to the reorganization of the revision option parsing code. The "-i" is completely ignored, but works fine in "git log --grep -i". What happens is that the code for "-i" looks for revs->grep_filter; if it is NULL, we do nothing, since there are no grep filters. But that is obviously not correct, since we want it to influence the later --grep option. Doing it the other way around works, since "-i" just impacts the existing grep_filter option. Instead, we now always initialize the grep_filter member and just fill in options and patterns as we get them. This means that we can no longer check grep_filter for NULL, but instead must check the pattern list to see if we have any actual patterns. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-07-19
|\ | | | | | | | | | | | | | | | | * maint: GIT 1.5.6.4 builtin-rm: fix index lock file path http-fetch: do not SEGV after fetching a bad pack idx file rev-list: honor --quiet option api-run-command.txt: typofix
| * rev-list: honor --quiet optionJunio C Hamano2008-07-17
| | | | | | | | | | | | | | | | Nick Andrew noticed that rev-list lets --quiet option to be parsed by underlying diff_options parser but did not pick up the result. This resulted in --quiet option to become effectively a no-op. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'sb/dashless'Junio C Hamano2008-07-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * sb/dashless: Make usage strings dash-less t/: Use "test_must_fail git" instead of "! git" t/test-lib.sh: exit with small negagive int is ok with test_must_fail Conflicts: builtin-blame.c builtin-mailinfo.c builtin-mailsplit.c builtin-shortlog.c git-am.sh t/t4150-am.sh t/t4200-rerere.sh
| * | Make usage strings dash-lessStephan Beyer2008-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ph/parseopt-step-blame'Junio C Hamano2008-07-13
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ph/parseopt-step-blame: revisions: refactor handle_revision_opt into parse_revision_opt. git-shortlog: migrate to parse-options partially. git-blame: fix lapsus git-blame: migrate to incremental parse-option [2/2] git-blame: migrate to incremental parse-option [1/2] revisions: split handle_revision_opt() from setup_revisions() parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option. parse-opt: fake short strings for callers to believe in. parse-opt: do not print errors on unknown options, return -2 intead. parse-opt: create parse_options_step. parse-opt: Export a non NORETURN usage dumper. parse-opt: have parse_options_{start,end}. git-blame --reverse builtin-blame.c: allow more than 16 parents builtin-blame.c: move prepare_final() into a separate function. rev-list --children revision traversal: --children option
| * | Merge branch 'jc/blame' (early part) into HEADJunio C Hamano2008-07-08
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'jc/blame' (early part): git-blame --reverse builtin-blame.c: allow more than 16 parents builtin-blame.c: move prepare_final() into a separate function. rev-list --children revision traversal: --children option Conflicts: Documentation/rev-list-options.txt revision.c
| | * rev-list --childrenJunio C Hamano2008-04-12
| | | | | | | | | | | | | | | | | | | | | Just like --parents option shows the parents of commits, this shows the children of commits. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Move read_revisions_from_stdin from builtin-rev-list.c to revision.cAdam Brewster2008-07-05
|/ / | | | | | | | | | | | | | | | | Reading rev-list parameters from the command line can be reused by commands other than rev-list. Move this function to more "library-ish" place to promote code reuse. Signed-off-by: Adam Brewster <asb@bu.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/config-cb'v1.5.6-rc0Junio C Hamano2008-05-25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | * js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
| * | Provide git_config with a callback-data parameterJohannes Schindelin2008-05-14
| |/ | | | | | | | | | | | | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log --graph --left-right: show left/right information in place of '*'Adam Simpkins2008-05-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the --graph option, the graph already outputs 'o' instead of '*' for boundary commits. Make it emit '<' or '>' when --left-right is specified. (This change also disables the '^' prefix for UNINTERESTING commits. The graph code currently doesn't print anything special for these commits, since it assumes no UNINTERESTING, non-BOUNDARY commits are displayed. This is potentially a bug if UNINTERESTING non-BOUNDARY commits can actually be displayed via some code path.) [jc: squashed the left-right change from Dscho and Adam's fixup into one] Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log and rev-list: add --graph optionAdam Simpkins2008-05-05
| | | | | | | | | | | | | | | | This new option causes a text-based representation of the history to be printed to the left of the normal output. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | revision API: split parent rewriting and parent printing optionsAdam Simpkins2008-05-05
|/ | | | | | | | This change allows parent rewriting to be performed without causing the log and rev-list commands to print the parents. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add --reverse to the git-rev-list usage stringKevin Ballard2008-03-19
| | | | | | | | git-rev-list accepts --reverse, as documented in the manpage, but the usage string does not list it. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mk/maint-parse-careful'Junio C Hamano2008-03-02
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * mk/maint-parse-careful: receive-pack: use strict mode for unpacking objects index-pack: introduce checking mode unpack-objects: prevent writing of inconsistent objects unpack-object: cache for non written objects add common fsck error printing function builtin-fsck: move common object checking code to fsck.c builtin-fsck: reports missing parent commits Remove unused object-ref code builtin-fsck: move away from object-refs to fsck_walk add generic, type aware object chain walker Conflicts: Makefile builtin-fsck.c
| * Remove unused object-ref codeMartin Koegler2008-02-25
| | | | | | | | | | Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: add --branches, --tags and --remotesUwe Kleine-König2008-02-29
| | | | | | | | | | | | | | | | | | | | | | | | | | These flags are already known to rev-parse and have the same meaning. This patch allows to run gitk as follows: gitk --branches --not --remotes to show only your local work. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'lt/revision-walker'Junio C Hamano2008-02-20
|\ \ | | | | | | | | | | | | * lt/revision-walker: Add "--show-all" revision walker flag for debugging
| * | Add "--show-all" revision walker flag for debuggingLinus Torvalds2008-02-13
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! This adds a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them (it also fixes a logic error for !verbose_header for boundary commits - we should show the '-' even if left_right isn't shown). A separate patch to gitk to teach it the new '^' was sent to paulus. With the change in place, it actually is interesting even for the cases that git doesn't have any problems with, ie for the kernel you can do: gitk -d --show-all v2.6.24.. and you see just how far down it has to parse things to see it all. The use of "-d" is a good idea, since the date-ordered toposort is much better at showing why it goes deep down (ie the date of some of those commits after 2.6.24 is much older, because they were merged from trees that weren't rebased). So I think this is a useful feature even for non-debugging - just to visualize what git does internally more. When it actually breaks out due to the "everybody_uninteresting()" case, it adds the uninteresting commits (both the one it's looking at now, and the list of pending ones) to the list This way, we really list *all* the commits we've looked at. Because we now end up listing commits we may not even have been parsed at all "show_log" and "show_commit" need to protect against commits that don't have a commit buffer entry. That second part is debatable just how it should work. Maybe we shouldn't show such entries at all (with this patch those entries do get shown, they just don't get any message shown with them). But I think this is a useful case. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | check return code of prepare_revision_walkMartin Koegler2008-02-17
|/ | | | | | | | A failure in prepare_revision_walk can be caused by a not parseable object. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Don't access line[-1] for a zero-length "line" from fgets.Jim Meyering2008-01-04
| | | | | | | | | | | | | | | A NUL byte at beginning of file, or just after a newline would provoke an invalid buf[-1] access in a few places. * builtin-grep.c (cmd_grep): Don't access buf[-1]. * builtin-pack-objects.c (get_object_list): Likewise. * builtin-rev-list.c (read_revisions_from_stdin): Likewise. * bundle.c (read_bundle_header): Likewise. * server-info.c (read_pack_info_file): Likewise. * transport.c (insert_packed_refs): Likewise. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'lt/rev-list-interactive'Junio C Hamano2007-11-18
|\ | | | | | | | | | | | | | | | | * lt/rev-list-interactive: Fix parent rewriting in --early-output revision walker: mini clean-up Enhance --early-output format Add "--early-output" log flag for interactive GUI use Simplify topo-sort logic
| * Fix parent rewriting in --early-outputLinus Torvalds2007-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We cannot tell a node that has been checked and found not to be interesting (which does not have the TREECHANGE flag) from a node that hasn't been checked if it is interesting or not, without relying on something else, such as object->parsed. But an object can get the "parsed" flag for other reasons. Which means that "TREECHANGE" has the wrong polarity. This changes the way how the path pruning logic marks an uninteresting commits. From now on, we consider a commit interesting by default, and explicitly mark the ones we decided to prune. The flag is renamed to "TREESAME". Then, this fixes the logic to show the early output with incomplete pruning. It basically says "a commit that has TREESAME set is kind-of-UNINTERESTING", but obviously in a different way than an outright UNINTERESTING commit. Until we parse and examine enough parents to determine if a commit becomes surely "kind-of-UNINTERESTING", we avoid rewriting the ancestry so that later rounds can fix things up. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * revision walker: mini clean-upLinus Torvalds2007-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the unnecessary indirection of "revs->prune_fn", since that function is always the same one (or NULL), and there is in fact not even an abstraction reason to make it a function (i.e. its not called from some other file and doesn't allow us to keep the function itself static or anything like that). It then just replaces it with a bit that says "prune or not", and if not pruning, every commit gets TREECHANGE. That in turn means that - if (!revs->prune_fn || (flags & TREECHANGE)) - if (revs->prune_fn && !(flags & TREECHANGE)) just become - if (flags & TREECHANGE) - if (!(flags & TREECHANGE)) respectively. Together with adding the "single_parent()" helper function, the "complex" conditional now becomes if (!(flags & TREECHANGE) && rev->dense && single_parent(commit)) continue; Also indirection of "revs->dense" checking is thrown away the same way, because TREECHANGE bit is set appropriately now. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: Introduce --quiet to avoid /dev/null redirectsShawn O. Pearce2007-11-11
|/ | | | | | | | | | | | Some uses of git-rev-list are to run it with --objects to see if a range of objects between two or more commits is fully connected or not. In such a case the caller doesn't care about the actual object names or hash hints so formatting this data only for it to be dumped to /dev/null by a redirect is a waste of CPU time. If all the caller needs is the exit status then --quiet can be used to bypass the commit and object formatting. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* format-patch -s: add MIME encoding header if signer's name requires soJunio C Hamano2007-11-01
| | | | | | | | | | | When the body of the commit log message contains a non-ASCII character, format-patch correctly emitted the encoding header to mark the resulting message as such. However, if the original message was fully ASCII, the command line switch "-s" was given to add a new sign-off, and the signer's name was not ASCII only, the resulting message would have contained non-ASCII character but was not marked as such. Signed-off-by: Junio C Hamano <gitster@pobox.com>