summaryrefslogtreecommitdiff
path: root/revision.h
AgeCommit message (Collapse)AuthorFilesLines
2009-04-18Merge branch 'lt/pack-object-memuse'Libravatar Junio C Hamano1-0/+2
* 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
2009-04-12show_object(): push path_name() call further downLibravatar Linus Torvalds1-1/+1
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>
2009-04-12process_{tree,blob}: show objects without bufferingLibravatar Linus Torvalds1-0/+2
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>
2009-04-06Merge branch 'sb/format-patch-patchname'Libravatar Junio C Hamano1-0/+2
* sb/format-patch-patchname: format_sanitized_subject: Don't trim past initial length of strbuf log-tree: fix patch filename computation in "git format-patch" format-patch: --numbered-files and --stdout aren't mutually exclusive format-patch: --attach/inline uses filename instead of SHA1 format-patch: move get_patch_filename() into log-tree format-patch: pass a commit to reopen_stdout() format-patch: construct patch filename in one function pretty.c: add %f format specifier to format_commit_message()
2009-04-01Merge branch 'jc/maint-1.6.0-keep-pack'Libravatar Junio C Hamano1-1/+0
* jc/maint-1.6.0-keep-pack: pack-objects: don't loosen objects available in alternate or kept packs t7700: demonstrate repack flaw which may loosen objects unnecessarily Remove --kept-pack-only option and associated infrastructure pack-objects: only repack or loosen objects residing in "local" packs git-repack.sh: don't use --kept-pack-only option to pack-objects t7700-repack: add two new tests demonstrating repacking flaws Conflicts: t/t7700-repack.sh
2009-03-22format-patch: --attach/inline uses filename instead of SHA1Libravatar Stephen Boyd1-0/+2
Currently when format-patch is used with --attach or --inline the patch attachment has the SHA1 of the commit for its filename. This replaces the SHA1 with the filename used by format-patch when outputting to files. Fix tests relying on the SHA1 output and add a test showing how the --suffix option affects the attachment filename output. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20Remove --kept-pack-only option and associated infrastructureLibravatar Brandon Casey1-1/+0
This option to pack-objects/rev-list was created to improve the -A and -a options of repack. It was found to be lacking in that it did not provide the ability to differentiate between local and non-local kept packs, and found to be unnecessary since objects residing in local kept packs can be filtered out by the --honor-pack-keep option. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-11Merge branch 'jc/maint-1.6.0-keep-pack'Libravatar Junio C Hamano1-4/+2
* jc/maint-1.6.0-keep-pack: is_kept_pack(): final clean-up Simplify is_kept_pack() Consolidate ignore_packed logic more has_sha1_kept_pack(): take "struct rev_info" has_sha1_pack(): refactor "pretend these packs do not exist" interface git-repack: resist stray environment variable
2009-02-28is_kept_pack(): final clean-upLibravatar Junio C Hamano1-3/+0
Now is_kept_pack() is just a member lookup into a structure, we can write it as such. Also rewrite the sole caller of has_sha1_kept_pack() to switch on the criteria the callee uses (namely, revs->kept_pack_only) between calling has_sha1_kept_pack() and has_sha1_pack(), so that these two callees do not have to take a pointer to struct rev_info as an argument. This removes the header file dependency issue temporarily introduced by the earlier commit, so we revert changes associated to that as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28Simplify is_kept_pack()Libravatar Junio C Hamano1-5/+3
This removes --unpacked=<packfile> parameter from the revision parser, and rewrites its use in git-repack to pass a single --kept-pack-only option instead. The new --kept-pack-only option means just that. When this option is given, is_kept_pack() that used to say "not on the --unpacked=<packfile> list" now says "the packfile has corresponding .keep file". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28Consolidate ignore_packed logic moreLibravatar Junio C Hamano1-0/+1
This refactors three loops that check if a given packfile is on the ignore_packed list into a function is_kept_pack(). The function returns false for a pack on the list, and true for a pack not on the list, because this list is solely used by "git repack" to pass list of packfiles that do not have corresponding .keep files, i.e. a packfile not on the list is "kept". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28has_sha1_kept_pack(): take "struct rev_info"Libravatar Junio C Hamano1-0/+2
Its "ignore_packed" parameter always comes from struct rev_info. This patch makes the function take a pointer to the surrounding structure, so that the refactoring in the next patch becomes easier to review. There is an unfortunate header file dependency and the easiest workaround is to temporarily move the function declaration from cache.h to revision.h; this will be moved back to cache.h once the function loses this "ignore_packed" parameter altogether in the later part of the series. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-21format-patch: track several referencesLibravatar Thomas Rast1-1/+1
Currently, format-patch can only track a single reference (the In-Reply-To:) for each mail. To ensure proper threading, we should list all known references for every mail. Change the rev_info.ref_message_id field to a string_list, so that we can append references at will, and change the output formatting routines to print all of them in the References: header. The last entry in the list is implicitly assumed to be the In-Reply-To:, which gives output consistent with RFC 2822: The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). Note that this is just preparatory work; nothing uses it yet, so all "References:" fields in the output are still only one deep. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04revision traversal: '--simplify-by-decoration'Libravatar Linus Torvalds1-0/+1
With this, you can simplify history not by the contents of the tree, but whether a commit has been named (ie it's referred to by some branch or tag) or not. This makes it possible to see the relationship between different named commits, without actually seeing any of the details. When used with pathspec, you would get the usual view that is limited to the commits that change the contents of the tree plus commits that are named. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04Make '--decorate' set an explicit 'show_decorations' flagLibravatar Linus Torvalds1-0/+1
We will want to add decorations without necessarily showing them, so add an explicit revisions info flag as to whether we're showing decorations or not. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04Add a 'source' decorator for commitsLibravatar Linus Torvalds1-0/+1
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>
2008-09-18Merge branch 'tr/rev-list-reverse'Libravatar Junio C Hamano1-0/+1
* tr/rev-list-reverse: t6013: replace use of 'tac' with equivalent Perl rev-list: fix --reverse interaction with --parents
2008-09-02Merge branch 'tr/filter-branch'Libravatar Junio C Hamano1-0/+2
* tr/filter-branch: revision --simplify-merges: make it a no-op without pathspec revision --simplify-merges: do not leave commits unprocessed revision --simplify-merges: use decoration instead of commit->util field Documentation: rev-list-options: move --simplify-merges documentation filter-branch: use --simplify-merges filter-branch: fix ref rewriting with --subdirectory-filter filter-branch: Extend test to show rewriting bug Topo-sort before --simplify-merges revision traversal: show full history with merge simplification revision.c: whitespace fix
2008-08-29rev-list: fix --reverse interaction with --parentsLibravatar Thomas Rast1-0/+1
--reverse did not interact well with --parents, as the included test case shows: in a history like A--B. \ \ `C--M--D the command git rev-list --reverse --parents --full-history HEAD erroneously lists D as having no parents at all. (Without --reverse, it correctly lists M.) This is caused by the machinery driving --reverse: it first grabs all commits through the normal routines, then runs them through the same routines again, effectively simplifying them twice. Fix this by moving the --reverse one level up, into get_revision(). This way we can cleanly grab all commits via the normal calls, then just pop them off the list one by one without interfering with get_revision_internal(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-24Fix "git log -i --grep"Libravatar Jeff King1-1/+2
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>
2008-08-20revision.h: make show_early_output an extern which is defined in revision.cLibravatar Brandon Casey1-1/+1
The variable show_early_output is defined in revision.c and should be declared extern in revision.h so that the linker does not complain about multiply defined variables. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14revision --simplify-merges: use decoration instead of commit->util fieldLibravatar Junio C Hamano1-0/+1
The users of revision walking machinery may want to use the util pointer for their own use. Use decoration to hold the data needed during merge simplification instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-02revision traversal: show full history with merge simplificationLibravatar Junio C Hamano1-0/+1
The --full-history traversal keeps all merges in addition to non-merge commits that touch paths in the given pathspec. This is useful to view both sides of a merge in a topology like this: A---M---o / / ---O---B even when A and B makes identical change to the given paths. The revision traversal without --full-history aims to come up with the simplest history to explain the final state of the tree, and one of the side branches can be pruned away. The behaviour to keep all merges however is inconvenient if neither A nor B touches the paths we are interested in. --full-history reduces the topology to: ---O---M---o in such a case, without removing M. This adds a post processing phase on top of --full-history traversal to remove needless merges from the resulting history. The idea is to compute, for each commit in the "full history" result set, the commit that should replace it in the simplified history. The commit to replace it in the final history is determined as follows: * In any case, we first figure out the replacement commits of parents of the commit we are looking at. The commit we are looking at is rewritten as if the replacement commits of its original parents are its parents. While doing so, we reduce the redundant parents from the rewritten parent list by not just removing the identical ones, but also removing a parent that is an ancestor of another parent. * After the above parent simplification, if the commit is a root commit, an UNINTERESTING commit, a merge commit, or modifies the paths we are interested in, then the replacement commit of the commit is itself. In other words, such a commit is not dropped from the final result. The first point above essentially means that the history is rewritten in the bottom up direction. We can rewrite the parent list of a commit only after we know how all of its parents are rewritten. This means that the processing needs to happen on the full history (i.e. after limit_list()). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23sort_in_topological_order(): avoid setting a commit flagLibravatar Johannes Schindelin1-2/+1
We used to set the TOPOSORT flag of commits during the topological sorting, but we can just as well use the member "indegree" for it: indegree is now incremented by 1 in the cases where the commit used to have the TOPOSORT flag. This is the same behavior as before, since indegree could not be non-zero when TOPOSORT was unset. Incidentally, this fixes the bug in show-branch where the 8th column was not shown: show-branch sorts the commits in topological order, assuming that all the commit flags are available for show-branch's private matters. But this was not true: TOPOSORT was identical to the flag corresponding to the 8th ref. So the flags for the 8th column were unset by the topological sorting. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Merge branch 'ph/parseopt-step-blame'Libravatar Junio C Hamano1-0/+8
* 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
2008-07-13Merge branch 'jc/report-tracking'Libravatar Junio C Hamano1-0/+1
* jc/report-tracking: branch -r -v: do not spit out garbage stat_tracking_info(): clear object flags used during counting git-branch -v: show the remote tracking statistics git-status: show the remote tracking statistics Refactor "tracking statistics" code used by "git checkout"
2008-07-09revisions: refactor handle_revision_opt into parse_revision_opt.Libravatar Pierre Habouzit1-2/+5
It seems we're using handle_revision_opt the same way each time, have a wrapper around it that does the 9-liner we copy each time instead. handle_revision_opt can be static in the module for now, it's always possible to make it public again if needed. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08revisions: split handle_revision_opt() from setup_revisions()Libravatar Pierre Habouzit1-0/+4
Add two fields to struct rev_info: - .def to store --default argument; and - .show_merge 1-bit field. handle_revision_opt() is able to deal with any revision option, and consumes them, and leaves revision arguments or pseudo arguments (like --all, --not, ...) in place. For now setup_revisions() does a pass of handle_revision_opt() again so that code not using it in a parse-opt parser still work the same. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08Merge branch 'jc/blame' (early part) into HEADLibravatar Junio C Hamano1-0/+1
* '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
2008-07-05Move read_revisions_from_stdin from builtin-rev-list.c to revision.cLibravatar Adam Brewster1-0/+2
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>
2008-07-03stat_tracking_info(): clear object flags used during countingLibravatar Junio C Hamano1-0/+1
When left-right traversal counts the commits in a diverged history, it leaves the flags in the commits smudged, and we need to clear them before we return. Otherwise the caller cannot inspect other branches with this function again. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05log and rev-list: add --graph optionLibravatar Adam Simpkins1-1/+5
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>
2008-05-05revision API: split parent rewriting and parent printing optionsLibravatar Adam Simpkins1-1/+2
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>
2008-04-12revision traversal: --children optionLibravatar Junio C Hamano1-0/+1
This adds a new --children option to the revision machinery. In addition to the list of parents, child commits of each commit are computed and stored as a decoration to each commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10log: teach "terminator" vs "separator" mode to "--pretty=format"Libravatar Junio C Hamano1-1/+2
This attached patch introduces a single bit "use_terminator" in "struct rev_info", which is normally false (i.e. most formats use separator semantics) but by flipping it to true, you can ask for terminator semantics just like oneline format does. The function get_commit_format(), which is what parses "--pretty=" option, now takes a pointer to "struct rev_info" and updates its commit_format and use_terminator fields. It used to return the value of type "enum cmit_fmt", but all the callers assigned it to rev->commit_format. There are only two cases the code turns use_terminator on. Obviously, the traditional oneline format (--pretty=oneline) is one of them, and the new case is --pretty=tformat:... that acts like --pretty=format:... but flips the bit on. With this, "--pretty=tformat:%H %s" acts like --pretty=oneline. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'db/cover-letter'Libravatar Junio C Hamano1-1/+1
* db/cover-letter: Improve collection of information for format-patch --cover-letter Add API access to shortlog t4014: Replace sed's non-standard 'Q' by standard 'q' Support a --cc=<email> option in format-patch Combine To: and Cc: headers Fix format.headers not ending with a newline Add tests for extra headers in format-patch Add a --cover-letter option to format-patch Export some email and pretty-printing functions Improve message-id generation flow control for format-patch Add more tests for format-patch Conflicts: builtin-log.c builtin-shortlog.c pretty.c
2008-02-19Improve message-id generation flow control for format-patchLibravatar Daniel Barkalow1-1/+1
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13Add "--show-all" revision walker flag for debuggingLibravatar Linus Torvalds1-0/+1
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>
2007-12-11shortlog: default to HEAD when the standard input is a ttyLibravatar Junio C Hamano1-0/+2
Instead of warning the user that it is expecting git log output from the standard input (and waiting for the user to type the log from the keyboard, which is a silly thing to do), default to traverse from HEAD when there is no rev parameter given and the standard input is a tty. This factors out a useful helper "add_head()" from builtin-diff.c to a more appropriate place revision.c while renaming it to more descriptive name add_head_to_pending(), as that is what the function is about. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14Fix parent rewriting in --early-outputLibravatar Linus Torvalds1-1/+1
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>
2007-11-05revision walker: mini clean-upLibravatar Linus Torvalds1-4/+1
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>
2007-11-05Enhance --early-output formatLibravatar Linus Torvalds1-0/+8
This makes --early-output a bit more advanced, and actually makes it generate multiple "Final output:" headers as it updates things asynchronously. I realize that the "Final output:" line is now illogical, since it's not really final until it also says "done", but It now _always_ generates a "Final output:" header in front of any commit list, and that output header gives you a *guess* at the maximum number of commits available. However, it should be noted that the guess can be completely off: I do a reasonable job estimating it, but it is not meant to be exact. So what happens is that you may get output like this: - at 0.1 seconds: Final output: 2 incomplete .. 2 commits listed .. - half a second later: Final output: 33 incomplete .. 33 commits listed .. - another half a second after that: Final output: 71 incomplete .. 71 commits listed .. - another half second later: Final output: 136 incomplete .. 100 commits listed: we hit the --early-output limit, and .. will only output 100 commits, and after this you'll not .. see an "incomplete" report any more since you got as much .. early output as you asked for! - .. and then finally: Final output: 73106 done .. all the commits .. The above is a real-life scenario on my current kernel tree after having flushed all the caches. Tested with the experimental gitk patch that Paul sent out, and by looking at the actual log output (and verifying that my commit count guesses actually match real life fairly well). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04Add "--early-output" log flag for interactive GUI useLibravatar Linus Torvalds1-0/+4
This adds support for "--early-output[=n]" as a flag to the "git log" family of commands. This allows GUI programs to state that they want to get some output early, in order to be able to show at least something quickly, even if the full output may take longer to generate. If no count is specified, a default count of a hundred commits will be used, although the actual numbr of commits output may be smaller depending on how many commits were actually found in the first tenth of a second (or if *everything* was found before that, in which case no early output will be provided, and only the final list is made available). When the full list is generated, there will be a "Final output:" string prepended to it, regardless of whether any early commits were shown or not, so that the consumer can always know the difference between early output and the final list. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04Simplify topo-sort logicLibravatar Linus Torvalds1-3/+1
.. by not using quite so much indirection. This currently grows the "struct commit" a bit, which could be avoided by using a union for "util" and "indegree" (the topo-sort used to use "util" anyway, so you cannot use them together), but for now the goal of this was to simplify, not optimize. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-14Add --log-size to git log to print message sizeLibravatar Marco Costalba1-0/+1
With this option git-log prints log message size just before the corresponding message. Porcelain tools could use this to speedup parsing of git-log output. Note that size refers to log message only. If also patch content is shown its size is not included. In case it is not possible to know the size upfront size value is set to zero. Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-08More missing staticLibravatar Junio C Hamano1-3/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-06Handle return code of parse_commit in revision machineryLibravatar Alex Riesen1-1/+1
This fixes a crash in broken repositories where random commits suddenly disappear. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25Add --date={local,relative,default}Libravatar Junio C Hamano1-2/+2
This adds --date={local,relative,default} option to log family of commands, to allow displaying timestamps in user's local timezone, relative time, or the default format. Existing --relative-date option is a synonym of --date=relative; we could probably deprecate it in the long run. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-24store mode in rev_list, if <tree>:<filename> syntax is usedLibravatar Martin Koegler1-0/+1
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-11git-log --cherry-pick A...BLibravatar Junio C Hamano1-0/+1
This is meant to be a saner replacement for "git-cherry". When used with "A...B", this filters out commits whose patch text has the same patch-id as a commit on the other side. It would probably most useful to use with --left-right. Signed-off-by: Junio C Hamano <junkio@cox.net>