summaryrefslogtreecommitdiff
path: root/revision.c
AgeCommit message (Collapse)AuthorFilesLines
2012-02-21Merge branch 'jk/grep-binary-attribute' into maintLibravatar Junio C Hamano1-1/+0
* jk/grep-binary-attribute: grep: pre-load userdiff drivers when threaded grep: load file data after checking binary-ness grep: respect diff attributes for binary-ness grep: cache userdiff_driver in grep_source grep: drop grep_buffer's "name" parameter convert git-grep to use grep_source interface grep: refactor the concept of "grep source" into an object grep: move sha1-reading mutex into low-level code grep: make locking flag global
2012-02-05Merge branch 'jc/maint-log-first-parent-pathspec' into maintLibravatar Junio C Hamano1-1/+9
* jc/maint-log-first-parent-pathspec: Making pathspec limited log play nicer with --first-parent
2012-02-02grep: drop grep_buffer's "name" parameterLibravatar Jeff King1-1/+0
Before the grep_source interface existed, grep_buffer was used by two types of callers: 1. Ones which pulled a file into a buffer, and then wanted to supply the file's name for the output (i.e., git grep). 2. Ones which really just wanted to grep a buffer (i.e., git log --grep). Callers in set (1) should now be using grep_source. Callers in set (2) always pass NULL for the "name" parameter of grep_buffer. We can therefore get rid of this now-useless parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-19Making pathspec limited log play nicer with --first-parentLibravatar Junio C Hamano1-1/+9
In a topic branch workflow, you often want to find the latest commit that merged a side branch that touched a particular area of the system, so that a new topic branch to work on that area can be forked from that commit. For example, I wanted to find an appropriate fork-point to queue Luke's changes related to git-p4 in contrib/fast-import/. "git log --first-parent" traverses the first-parent chain, and "-m --stat" shows the list of paths touched by commits including merge commits. We could ask the question this way: # What is the latest commit that touched that path? $ git log --first-parent --oneline -m --stat master | sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates', 2012-01-06) was such a commit. But a more natural way to spell this question is this: $ git log --first-parent --oneline -m --stat -1 master -- \ contrib/fast-import/git-p4 Unfortunately, this does not work. It finds ecb7cf9 (git-p4: rewrite view handling, 2012-01-02). This commit is a part of the merged topic branch and is _not_ on the first-parent path from the 'master': $ git show-branch 8cbfc11 ecb7cf9 ! [8cbfc11] Merge branch 'pw/p4-view-updates' ! [ecb7cf9] git-p4: rewrite view handling -- - [8cbfc11] Merge branch 'pw/p4-view-updates' + [8cbfc11^2] git-p4: view spec documentation ++ [ecb7cf9] git-p4: rewrite view handling The problem is caused by the merge simplification logic when it inspects the merge commit 8cbfc11. In this case, the history leading to the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked, and the result of the merge is simply a copy from the tip of the topic branch in the view limited by the given pathspec. The merge simplification logic discards the history on the mainline side of the merge, and pretends as if the sole parent of the merge is its second parent, i.e. the tip of the topic. While this simplification is correct in the general case, it is at least surprising if not outright wrong when the user explicitly asked to show the first-parent history. Here is an attempt to fix this issue, by not allowing us to compare the merge result with anything but the first parent when --first-parent is in effect, to avoid the history traversal veering off to the side branch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-12log: --show-signatureLibravatar Junio C Hamano1-0/+2
This teaches the "log" family of commands to pass the GPG signature in the commit objects to "gpg --verify" via the verify_signed_buffer() interface used to verify signed tag objects. E.g. $ git show --show-signature -s HEAD shows GPG output in the header part of the output. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-13Merge branch 'rs/pending'Libravatar Junio C Hamano1-2/+10
* rs/pending: commit: factor out clear_commit_marks_for_object_array checkout: use leak_pending flag bundle: use leak_pending flag bisect: use leak_pending flag revision: add leak_pending flag checkout: use add_pending_{object,sha1} in orphan check revision: factor out add_pending_sha1 checkout: check for "Previous HEAD" notice in t2020 Conflicts: builtin/checkout.c revision.c
2011-10-13Merge branch 'nd/maint-autofix-tag-in-head'Libravatar Junio C Hamano1-2/+4
* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c
2011-10-05Merge branch 'jc/fetch-verify'Libravatar Junio C Hamano1-0/+5
* jc/fetch-verify: fetch: verify we have everything we need before updating our ref rev-list --verify-object list-objects: pass callback data to show_objects()
2011-10-05Merge branch 'jc/traverse-commit-list'Libravatar Junio C Hamano1-0/+41
* jc/traverse-commit-list: revision.c: update show_object_with_name() without using malloc() revision.c: add show_object_with_name() helper function rev-list: fix finish_object() call
2011-10-05Merge branch 'bk/ancestry-path'Libravatar Junio C Hamano1-10/+43
* bk/ancestry-path: t6019: avoid refname collision on case-insensitive systems revision: do not include sibling history in --ancestry-path output revision: keep track of the end-user input from the command line rev-list: Demonstrate breakage with --ancestry-path --all
2011-10-03revision: add leak_pending flagLibravatar René Scharfe1-1/+2
The new flag leak_pending in struct rev_info can be used to prevent prepare_revision_walk from freeing the list of pending objects. It will still forget about them, so it really is leaked. This behaviour may look weird at first, but it can be useful if the pointer to the list is saved before calling prepare_revision_walk. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-03revision: factor out add_pending_sha1Libravatar René Scharfe1-3/+8
This function is a combination of the static get_reference and add_pending_object. It can be used to easily queue objects by hash. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-18Accept tags in HEAD or MERGE_HEADLibravatar Nguyễn Thái Ngọc Duy1-2/+4
HEAD and MERGE_HEAD (among other branch tips) should never hold a tag. That can only be caused by broken tools and is cumbersome to fix by an end user with: $ git update-ref HEAD $(git rev-parse HEAD^{commit}) which may look like a magic to a new person. Be easy, warn users (so broken tools can be fixed if they bother to report) and move on. Be robust, if the given SHA-1 cannot be resolved to a commit object, die (therefore return value is always valid). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-01rev-list --verify-objectLibravatar Junio C Hamano1-0/+5
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>
2011-08-25revision: do not include sibling history in --ancestry-path outputLibravatar Junio C Hamano1-6/+10
If the commit specified as the bottom of the commit range has a direct parent that has another child commit that contributed to the resulting history, "rev-list --ancestry-path" was confused and listed that side history as well, due to the command line parser subtlety corrected by the previous commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25revision: keep track of the end-user input from the command lineLibravatar Junio C Hamano1-4/+33
Given a complex set of revision specifiers on the command line, it is too late to look at the flags of the objects in the initial traversal list at the beginning of limit_list() in order to determine what the objects the end-user explicitly listed on the command line were. The process to move objects from the pending array to the traversal list may have marked objects that are not mentioned as UNINTERESTING, when handle_commit() marked the parents of UNINTERESTING commits mentioned on the command line by calling mark_parents_uninteresting(). This made "rev-list --ancestry-path ^A ..." to mistakenly list commits that are descendants of A's parents but that are not descendants of A itself, as ^A from the command line causes A and its parents marked as UNINTERESTING before coming to limit_list(), and we try to enumerate the commits that are descendants of these commits that are UNINTERESTING before we start walking the history. It actually is too late even if we inspected the pending object array before calling prepare_revision_walk(), as some of the same objects might have been mentioned twice, once as positive and another time as negative. The "rev-list --some-option A --not --all" command may want to notice, even if the resulting set is empty, that the user showed some interest in "A" and do something special about it. Prepare a separate array to keep track of what syntactic element was used to cause each object to appear in the pending array from the command line, and populate it as setup_revisions() parses the command line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22revision.c: update show_object_with_name() without using malloc()Libravatar Junio C Hamano1-14/+36
Allocating and then immediately freeing temporary memory a million times when listing a million objects is distasteful. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22revision.c: add show_object_with_name() helper functionLibravatar Junio C Hamano1-0/+19
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>
2011-05-29Merge branch 'jc/notes-batch-removal'Libravatar Junio C Hamano1-2/+13
* jc/notes-batch-removal: show: --ignore-missing notes remove: --stdin reads from the standard input notes remove: --ignore-missing notes remove: allow removing more than one
2011-05-25Merge branch 'js/log-abbrev-commit-config'Libravatar Junio C Hamano1-0/+3
* js/log-abbrev-commit-config: Add log.abbrevCommit config variable "git log -h": typofix misspelled 'suppress'
2011-05-23Merge branch 'jc/magic-pathspec'Libravatar Junio C Hamano1-0/+14
* jc/magic-pathspec: setup.c: Fix some "symbol not declared" sparse warnings t3703: Skip tests using directory name ":" on Windows revision.c: leave a note for "a lone :" enhancement t3703, t4208: add test cases for magic pathspec rev/path disambiguation: further restrict "misspelled index entry" diag fix overslow :/no-such-string-ever-existed diagnostics fix overstrict :<path> diagnosis grep: use get_pathspec() correctly pathspec: drop "lone : means no pathspec" from get_pathspec() Revert "magic pathspec: add ":(icase)path" to match case insensitively" magic pathspec: add ":(icase)path" to match case insensitively magic pathspec: futureproof shorthand form magic pathspec: add tentative ":/path/from/top/level" pathspec support
2011-05-19Merge branch 'jc/maint-pathspec-stdin-and-cmdline'Libravatar Junio C Hamano1-52/+28
* jc/maint-pathspec-stdin-and-cmdline: setup_revisions(): take pathspec from command line and --stdin correctly Conflicts: revision.c
2011-05-19show: --ignore-missingLibravatar Junio C Hamano1-2/+13
Instead of barfing, simply ignore bad object names seen in the input. This is useful when reading from "git notes list" output that may refer to objects that have already been garbage collected. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-18Add log.abbrevCommit config variableLibravatar Jay Soffian1-0/+3
Add log.abbrevCommit config variable as a convenience for users who often use --abbrev-commit with git log and friends. Allow the option to be overridden with --no-abbrev-commit. Per 635530a2fc and 4f62c2bc57, the config variable is ignored when log is given "--pretty=raw". (Also, a drive-by spelling correction in git log's short help.) Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-13Merge branch 'jn/setup-revisions-glob-and-friends-passthru'Libravatar Junio C Hamano1-65/+72
* jn/setup-revisions-glob-and-friends-passthru: revisions: allow --glob and friends in parse_options-enabled commands revisions: split out handle_revision_pseudo_opt function
2011-05-11Merge branch 'jc/maint-1.7.4-pathspec-stdin-and-cmdline'Libravatar Junio C Hamano1-52/+28
Update the fix for 1.7.5 maintenance track. * jc/maint-1.7.4-pathspec-stdin-and-cmdline: setup_revisions(): take pathspec from command line and --stdin correctly
2011-05-11revision.c: leave a note for "a lone :" enhancementLibravatar Junio C Hamano1-0/+14
If we later add a command in the log family that by default limit its operation to the current subdirectory, we would need to resurrect the "a lone ':' on the command line means no pathspec whatsoever". Now the codepath was cleaned up, we can do so in one place. Leave a note to mark where it is for later generations. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-11Merge branch 'jc/maint-1.6.6-pathspec-stdin-and-cmdline'Libravatar Junio C Hamano1-52/+28
* jc/maint-1.6.6-pathspec-stdin-and-cmdline: setup_revisions(): take pathspec from command line and --stdin correctly
2011-05-11Merge branch 'jc/maint-1.6.6-pathspec-stdin-and-cmdline'Libravatar Junio C Hamano1-52/+28
Update the fix for 1.7.4 maintenance track. * jc/maint-1.6.6-pathspec-stdin-and-cmdline: setup_revisions(): take pathspec from command line and --stdin correctly
2011-05-11setup_revisions(): take pathspec from command line and --stdin correctlyLibravatar Junio C Hamano1-52/+28
When the command line has "--" disambiguator, we take the remainder of argv[] as "prune_data", but when --stdin is given at the same time, we need to append to the existing prune_data and end up attempting to realloc(3) it. That would not work. Fix it by consistently using append_prune_data() throughout the input processing. Also avoid counting the number of existing paths in the function over and over again. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-21revisions: allow --glob and friends in parse_options-enabled commandsLibravatar Jonathan Nieder1-1/+13
As v1.6.0-rc2~42 (2008-07-31) explains, even pseudo-options like --not and --glob that need to be parsed in order with revisions should be marked handled by handle_revision_opt to avoid an error when parse_revision_opt callers like "git shortlog" encounter them. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-21revisions: split out handle_revision_pseudo_opt functionLibravatar Jonathan Nieder1-64/+59
As v1.6.0-rc2~42 (Allow "non-option" revision options in parse_option-enabled commands, 2008-07-31) explains, options handled by setup_revisions fall into two categories: 1. global options like --topo-order handled by parse_revision_opt, which can take detached arguments and can be parsed in advance; 2. pseudo-options that must be parsed in order with their revision counterparts, like --not and --all. The global options are taken care of by handle_revision_opt; the pseudo-options are currently in a deeply indented portion of setup_revisions. Give them their own function for easier reading. The only goal is to make setup_revisions easier to read straight through. No functional change intended. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-29revision.c: make --no-notes reset --notes listLibravatar Jeff King1-0/+6
With most command line options, later instances of an option override earlier ones. With cumulative options like "--notes", however, there is no way to say "forget the --notes I gave you before". Let's have --no-notes trigger this forgetting, so that: git log --notes=foo --no-notes --notes=bar will show only the "bar" notes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-29revision.c: support --notes command-line optionLibravatar Jeff King1-5/+10
We already have --show-notes, but it has a few shortcomings: 1. Using --show-notes=<ref> implies that we should also show the default notes. Which means you also need to use --no-standard-notes if you want to suppress them. 2. It is negated by --no-notes, which doesn't match. 3. It's too long to type. :) This patch introduces --notes, which behaves exactly like --show-notes, except that using "--notes=<ref>" does not imply showing the default notes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-29notes: refactor display notes default handlingLibravatar Jeff King1-2/+7
This is in preparation for more notes-related revision command-line options. The "suppress_default_notes" option is renamed to "use_default_notes", and is now a tri-state with values less than one indicating "not set". If the value is "not set", then we show default refs if and only if no other refs were given. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-29notes: refactor display notes extra refs fieldLibravatar Jeff King1-3/+1
There's no need to use an extra pointer, which just ends up leaking memory. The fact that the list is empty tells us the same thing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-29revision.c: refactor notes ref expansionLibravatar Jeff King1-6/+1
No need to do it ourselves when there is a library function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-26Merge branch 'mg/rev-list-n-parents'Libravatar Junio C Hamano1-7/+21
* mg/rev-list-n-parents: tests: avoid nonportable {foo,bar} glob rev-list --min-parents,--max-parents: doc, test and completion revision.c: introduce --min-parents and --max-parents options t6009: use test_commit() from test-lib.sh
2011-03-23revision.c: introduce --min-parents and --max-parents optionsLibravatar Michael J Gruber1-7/+21
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>
2011-03-22Merge branch 'mg/rev-list-one-side-only'Libravatar Junio C Hamano1-3/+79
* mg/rev-list-one-side-only: git-log: put space after commit mark t6007: test rev-list --cherry log --cherry: a synonym rev-list: documentation and test for --cherry-mark revision.c: introduce --cherry-mark rev-list/log: factor out revision mark generation rev-list: --left/right-only are mutually exclusive rev-list: documentation and test for --left/right-only t6007: Make sure we test --cherry-pick revlist.c: introduce --left/right-only for unsymmetric picking
2011-03-10git-log: put space after commit markLibravatar Michael J Gruber1-0/+9
Currently, commit marks (left, right, boundary, cherry) are output right before the commit sha1, which makes it difficult to copy sha1s. Sample output for "git log --oneline --cherry": =049c269 t6007: test rev-list --cherry Change this to = 049c269 t6007: test rev-list --cherry which matches exactly the current output of "git log --graph". Leave "git rev-list" output as is (no space) so that they do not break. Adjust "git-svn" which uses "git log --pretty=raw --boundary". Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09log --cherry: a synonymLibravatar Michael J Gruber1-1/+9
At the porcelain level, because by definition there are many more contributors than integrators, it makes sense to give a handy short-hand for --right-only used with --cherry-mark and --no-merges. Make it so. In other words, this provides "git cherry with rev-list interface". Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09revision.c: introduce --cherry-markLibravatar Michael J Gruber1-3/+18
for marking those commits which "--cherry-pick" would drop. The marker for those commits is '=' because '-' denotes a boundary commit already, even though 'git cherry' uses it. Nonequivalent commits are denoted '+' unless '--left-right' is used. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09rev-list/log: factor out revision mark generationLibravatar Michael J Gruber1-0/+16
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>
2011-02-21rev-list: --left/right-only are mutually exclusiveLibravatar Junio C Hamano1-0/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21revlist.c: introduce --left/right-only for unsymmetric pickingLibravatar Michael J Gruber1-0/+24
The existing "--cherry-pick" does not work with unsymmetric ranges (A..B) for obvious reasons. Introduce "--left-only" and "--right-only" which limit the output to commits on the respective sides of a symmetric range (i.e. only "<" resp. ">" commits as per "--left-right"). This is especially useful for things like git log --cherry-pick --right-only @{u}... which is much more flexible (and descriptive) than git cherry @{u} | sed -ne 's/^+ //p' and potentially more useful than git log --cherry-pick @{u}... Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03Convert ce_path_match() to use struct pathspecLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03struct rev_info: convert prune_data to struct pathspecLibravatar Nguyễn Thái Ngọc Duy1-7/+8
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03Convert struct diff_options to use struct pathspecLibravatar Nguyễn Thái Ngọc Duy1-5/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-22Merge branch 'tf/commit-list-prefix'Libravatar Junio C Hamano1-6/+6
* tf/commit-list-prefix: commit: Add commit_list prefix in two function names. Conflicts: sha1_name.c