summaryrefslogtreecommitdiff
path: root/revision.c
AgeCommit message (Collapse)AuthorFilesLines
2009-04-01Merge branch 'jc/maint-1.6.0-keep-pack'Libravatar Junio C Hamano1-8/+1
* 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-20Remove --kept-pack-only option and associated infrastructureLibravatar Brandon Casey1-8/+1
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-16/+9
* 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-1/+3
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-15/+5
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-28has_sha1_kept_pack(): take "struct rev_info"Libravatar Junio C Hamano1-1/+1
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-28has_sha1_pack(): refactor "pretend these packs do not exist" interfaceLibravatar Junio C Hamano1-1/+2
Most of the callers of this function except only one pass NULL to its last parameter, ignore_packed. Introduce has_sha1_kept_pack() function that has the function signature and the semantics of this function, and convert the sole caller that does not pass NULL to call this new function. All other callers and has_sha1_pack() lose the ignore_packed parameter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-24Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"Libravatar Nanako Shiraishi1-0/+4
These two are often used together but are too long to type. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-24Add --format that is a synonym to --prettyLibravatar Nanako Shiraishi1-1/+1
Some people prefer to call the pretty-print styles "format", and get annoyed to see "git log --format=short" fail. Introduce it as a synonym to --pretty so that both can be used. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Merge branch 'maint'Libravatar Junio C Hamano1-2/+4
* maint: revision traversal and pack: notice and die on missing commit
2009-02-11Merge branch 'maint-1.5.6' into maintLibravatar Junio C Hamano1-2/+4
* maint-1.5.6: revision traversal and pack: notice and die on missing commit
2009-02-11Merge branch 'maint-1.5.5' into maint-1.5.6Libravatar Junio C Hamano1-2/+4
* maint-1.5.5: revision traversal and pack: notice and die on missing commit Conflicts: revision.c
2009-02-11Merge branch 'maint-1.5.4' into maint-1.5.5Libravatar Junio C Hamano1-2/+4
* maint-1.5.4: revision traversal and pack: notice and die on missing commit
2009-02-11revision traversal and pack: notice and die on missing commitLibravatar Junio C Hamano1-2/+4
cc0e6c5 (Handle return code of parse_commit in revision machinery, 2007-05-04) attempted to tighten error checking in the revision machinery, but it wasn't enough. When get_revision_1() was asked for the next commit to return, it tries to read and simplify the parents of the commit to be returned, but an error while doing so was silently ignored and reported as a truncated history to the caller instead. This resulted in an early end of "git log" output or a pack that lacks older commits from "git pack-objects", without any error indication in the exit status from these commands, even though the underlying parse_commit() issues an error message to the end user. Note that the codepath in add_parents_list() that paints parents of an UNINTERESTING commit UNINTERESTING silently ignores the error when parse_commit() fails; this is deliberate and in line with aeeae1b (revision traversal: allow UNINTERESTING objects to be missing, 2009-01-27). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-05Merge branch 'js/maint-all-implies-HEAD' into maintLibravatar Junio C Hamano1-0/+1
* js/maint-all-implies-HEAD: bundle: allow the same ref to be given more than once revision walker: include a detached HEAD in --all
2009-01-31Merge branch 'jc/maint-allow-uninteresting-missing'Libravatar Junio C Hamano1-3/+7
* jc/maint-allow-uninteresting-missing: revision traversal: allow UNINTERESTING objects to be missing
2009-01-28revision traversal: allow UNINTERESTING objects to be missingLibravatar Junio C Hamano1-3/+7
Most of the existing codepaths were meant to treat missing uninteresting objects to be a silently ignored non-error, but there were a few places in handle_commit() and add_parents_to_list(), which are two key functions in the revision traversal machinery, that cared: - When a tag refers to an object that we do not have, we barfed. We ignore such a tag if it is painted as UNINTERESTING with this change. - When digging deeper into the ancestry chain of a commit that is already painted as UNINTERESTING, in order to paint its parents UNINTERESTING, we barfed if parse_parent() for a parent commit object failed. We can ignore such a parent commit object. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-25Merge branch 'js/maint-all-implies-HEAD'Libravatar Junio C Hamano1-0/+1
* js/maint-all-implies-HEAD: bundle: allow the same ref to be given more than once revision walker: include a detached HEAD in --all
2009-01-17revision walker: include a detached HEAD in --allLibravatar Johannes Schindelin1-0/+1
When HEAD is detached, --all should list it, too, logically, as a detached HEAD is by definition a temporary, unnamed branch. It is especially necessary to list it when garbage collecting, as the detached HEAD would be trashed. Noticed by Thomas Rast. Note that this affects creating bundles with --all; I contend that it is a good change to add the HEAD, so that cloning from such a bundle will give you a current branch. However, I had to fix t5701 as it assumed that --all does not imply HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-14Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Documentation: git-svn: fix example for centralized SVN clone Documentation: fix links to "everyday.html" revision.c: use proper data type in call to sizeof() within xrealloc
2008-11-14revision.c: use proper data type in call to sizeof() within xreallocLibravatar Brandon Casey1-1/+1
A type char** was being used instead of char*. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04revision traversal: '--simplify-by-decoration'Libravatar Linus Torvalds1-0/+27
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-04revision: make tree comparison functions take commits rather than treesLibravatar Linus Torvalds1-5/+9
This will make it easier to do various clever things that don't depend on the pure tree contents. It also makes the parameter passing much simpler - the callers doesn't really look at trees anywhere else, and it's really the function that should look at the low-level details. 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/+4
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-21/+17
* tr/rev-list-reverse: t6013: replace use of 'tac' with equivalent Perl rev-list: fix --reverse interaction with --parents
2008-09-04Merge branch 'jc/maint-log-grep'Libravatar Junio C Hamano1-17/+4
* jc/maint-log-grep: log --author/--committer: really match only with name part diff --cumulative is a sub-option of --dirstat bash completion: Hide more plumbing commands
2008-09-04log --author/--committer: really match only with name partLibravatar Junio C Hamano1-17/+4
When we tried to find commits done by AUTHOR, the first implementation tried to pattern match a line with "^author .*AUTHOR", which later was enhanced to strip leading caret and look for "^author AUTHOR" when the search pattern was anchored at the left end (i.e. --author="^AUTHOR"). This had a few problems: * When looking for fixed strings (e.g. "git log -F --author=x --grep=y"), the regexp internally used "^author .*x" would never match anything; * To match at the end (e.g. "git log --author='google.com>$'"), the generated regexp has to also match the trailing timestamp part the commit header lines have. Also, in order to determine if the '$' at the end means "match at the end of the line" or just a literal dollar sign (probably backslash-quoted), we would need to parse the regexp ourselves. An earlier alternative tried to make sure that a line matches "^author " (to limit by field name) and the user supplied pattern at the same time. While it solved the -F problem by introducing a special override for matching the "^author ", it did not solve the trailing timestamp nor tail match problem. It also would have matched every commit if --author=author was asked for, not because the author's email part had this string, but because every commit header line that talks about the author begins with that field name, regardleses of who wrote it. Instead of piling more hacks on top of hacks, this rethinks the grep machinery that is used to look for strings in the commit header, and makes sure that (1) field name matches literally at the beginning of the line, followed by a SP, and (2) the user supplied pattern is matched against the remainder of the line, excluding the trailing timestamp data. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-02Merge branch 'tr/filter-branch'Libravatar Junio C Hamano1-21/+181
* 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-21/+17
--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-22/+12
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-18revision --simplify-merges: make it a no-op without pathspecLibravatar Junio C Hamano1-1/+4
When we are not pruning there is no reason to run the merge simplification. Also avoid running topo-order sort twice. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-18revision --simplify-merges: do not leave commits unprocessedLibravatar Junio C Hamano1-1/+3
When we still do not know how parents of a commit simplify to, we should defer processing of the commit, not discard it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14revision --simplify-merges: use decoration instead of commit->util fieldLibravatar Junio C Hamano1-12/+37
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-07Merge branch 'ag/rewrite_one' into maintLibravatar Junio C Hamano1-6/+24
* ag/rewrite_one: Fix quadratic performance in rewrite_one.
2008-08-03Topo-sort before --simplify-mergesLibravatar Junio C Hamano1-3/+2
This makes the algorithm more honest about what it is doing. We start from an already limited, topo-sorted list, and postprocess it by simplifying the irrelevant merges away. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-02revision traversal: show full history with merge simplificationLibravatar Junio C Hamano1-20/+151
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-08-02revision.c: whitespace fixLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31Allow "non-option" revision options in parse_option-enabled commandsLibravatar Pierre Habouzit1-1/+1
Commands which use parse_options() but also call setup_revisions() must do their parsing in a two step process: 1. first, they parse all options. Anything unknown goes to parse_revision_opt() (which calls handle_revision_opt), which may claim the option or say "I don't recognize this" 2. the non-option remainder goes to setup_revisions() to actually get turned into revisions Some revision options are "non-options" in that they must be parsed in order with their revision counterparts in setup_revisions(). For example, "--all" functions as a pseudo-option expanding to all refs, and "--no-walk" affects refs after it on the command line, but not before. The revision option parser in step 1 recognizes such options and sets them aside for later parsing by setup_revisions(). However, the return value used from handle_revision_opt indicated "I didn't recognize this", which was wrong. It did, and it took appropriate action (even though that action was just deferring it for later parsing). Thus it should return "yes, I recognized this." Previously, these pseudo-options generated an error when used with parse_options parsers (currently just blame and shortlog). With this patch, they should work fine, enabling things like "git shortlog --all". Signed-off-by: Jeff King <peff@peff.net> Acked-By: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-16Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: Start preparing 1.5.6.4 release notes git fetch-pack: do not complain about "no common commits" in an empty repo rebase-i: keep old parents when preserving merges t7600-merge: Use test_expect_failure to test option parsing Fix buffer overflow in prepare_attr_stack Fix buffer overflow in git diff Fix buffer overflow in git-grep git-cvsserver: fix call to nonexistant cleanupWorkDir() Documentation/git-cherry-pick.txt et al.: Fix misleading -n description Conflicts: RelNotes
2008-07-16Fix buffer overflow in git diffLibravatar Dmitry Potapov1-2/+2
If PATH_MAX on your system is smaller than a path stored, it may cause buffer overflow and stack corruption in diff_addremove() and diff_change() functions when running git-diff Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-15Merge branch 'ag/rewrite_one'Libravatar Junio C Hamano1-6/+24
* ag/rewrite_one: Fix quadratic performance in rewrite_one.
2008-07-13Merge branch 'ph/parseopt-step-blame'Libravatar Junio C Hamano1-323/+268
* 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-13Fix quadratic performance in rewrite_one.Libravatar Alexander N. Gavrilov1-6/+24
Parent commits are usually older than their children. Thus, on each iteration of the loop in rewrite_one, add_parents_to_list traverses all commits previously processed by the loop. It performs very poorly in case of very long rewrite chains. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-09revisions: refactor handle_revision_opt into parse_revision_opt.Libravatar Pierre Habouzit1-2/+16
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-326/+222
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-2/+37
* '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/+17
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-05-25log --pretty: do not accept bogus "--prettyshort"Libravatar Junio C Hamano1-1/+6
... nor bogus "format.pretty = '=short'". Both are syntax errors. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25log --graph: do not accept log --graphbogusLibravatar Junio C Hamano1-1/+1
An obvious fix to the argument parser. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25get_revision(): honor the topo_order flag for boundary commitsLibravatar Adam Simpkins1-16/+57
Now get_revision() sorts the boundary commits when topo_order is set. Since sort_in_topological_order() takes a struct commit_list, it first places the boundary commits into revs->commits. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>