summaryrefslogtreecommitdiff
path: root/revision.c
AgeCommit message (Collapse)Author
2011-10-21Merge branch 'nd/maint-autofix-tag-in-head' into maintJunio C Hamano
* 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-16Merge branch 'bk/ancestry-path' into maintJunio C Hamano
* 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-09-18Accept tags in HEAD or MERGE_HEADNguyễn Thái Ngọc Duy
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-08-26revision: do not include sibling history in --ancestry-path outputJunio C Hamano
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-26revision: keep track of the end-user input from the command lineJunio C Hamano
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-05-30Merge branch 'jc/notes-batch-removal'Junio C Hamano
* 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'Junio C Hamano
* js/log-abbrev-commit-config: Add log.abbrevCommit config variable "git log -h": typofix misspelled 'suppress'
2011-05-23Merge branch 'jc/magic-pathspec'Junio C Hamano
* 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-20Merge branch 'jc/maint-pathspec-stdin-and-cmdline'Junio C Hamano
* jc/maint-pathspec-stdin-and-cmdline: setup_revisions(): take pathspec from command line and --stdin correctly Conflicts: revision.c
2011-05-19show: --ignore-missingJunio C Hamano
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 variableJay Soffian
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'Junio C Hamano
* 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'Junio C Hamano
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 :" enhancementJunio C Hamano
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'Junio C Hamano
* 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'Junio C Hamano
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 correctlyJunio C Hamano
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 commandsJonathan Nieder
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 functionJonathan Nieder
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 listJeff King
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 optionJeff King
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 handlingJeff King
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 fieldJeff King
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 expansionJeff King
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-27Merge branch 'mg/rev-list-n-parents'Junio C Hamano
* 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 optionsMichael J Gruber
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-23Merge branch 'mg/rev-list-one-side-only'Junio C Hamano
* 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-11git-log: put space after commit markMichael J Gruber
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 synonymMichael J Gruber
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-markMichael J Gruber
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 generationMichael J Gruber
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-22rev-list: --left/right-only are mutually exclusiveJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-22revlist.c: introduce --left/right-only for unsymmetric pickingMichael J Gruber
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 pathspecNguyễn Thái Ngọc Duy
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 pathspecNguyễn Thái Ngọc Duy
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 pathspecNguyễn Thái Ngọc Duy
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'Junio C Hamano
* tf/commit-list-prefix: commit: Add commit_list prefix in two function names. Conflicts: sha1_name.c
2010-12-13Merge branch 'jk/maint-reflog-bottom'Junio C Hamano
* jk/maint-reflog-bottom: reflogs: clear flags properly in corner case
2010-11-29commit: Add commit_list prefix in two function names.Thiago Farina
Add commit_list prefix to insert_by_date function and to sort_by_date, so it's clear that these functions refer to commit_list structure. Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24reflogs: clear flags properly in corner caseJeff King
The reflog-walking mechanism is based on the regular revision traversal. We just rewrite the parents of each commit in fake_reflog_parent to point to the commit in the next reflog entry instead of the real parents. However, the regular revision traversal tries not to show the same commit twice, and so sets the SHOWN flag on each commit it shows. In a reflog, however, we may want to see the same commit more than once if it appears in the reflog multiple times (which easily happens, for example, if you do a reset to a prior state). The fake_reflog_parent function takes care of this by clearing flags, including SHOWN. Unfortunately, it does so at the very end of the function, and it is possible to return early from the function if there is no fake parent to set up (e.g., because we are at the very first reflog entry on the branch). In such a case the flag is not cleared, and the entry is skipped by the revision traversal machinery as already shown. You can see this by walking the log of a ref which is set to its very first commit more than once (the test below shows such a situation). In this case the reflog walk will fail to show the entry for the initial creation of the ref. We don't want to simply move the flag-clearing to the top of the function; we want to make sure flags set during the fake-parent installation are also cleared. Instead, let's hoist the flag-clearing out of the fake_reflog_parent function entirely. It's not really about fake parents anyway, and the only caller is the get_revision machinery. Reported-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-22Merge branch 'mm/shortopt-detached'Junio C Hamano
* mm/shortopt-detached: log: parse separate option for --glob log: parse separate options like git log --grep foo diff: parse separate options --stat-width n, --stat-name-width n diff: split off a function for --stat-* option parsing diff: parse separate options like -S foo Conflicts: revision.c
2010-08-06log: parse separate option for --globMatthieu Moy
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06log: parse separate options like git log --grep fooMatthieu Moy
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07setup_revisions(): Allow walking history in a submoduleHeiko Voigt
By passing the path to a submodule in opt->submodule, the function can be used to walk history in the named submodule repository, instead of the toplevel repository. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'jp/string-list-api-cleanup'Junio C Hamano
* jp/string-list-api-cleanup: string_list: Fix argument order for string_list_append string_list: Fix argument order for string_list_lookup string_list: Fix argument order for string_list_insert_at_index string_list: Fix argument order for string_list_insert string_list: Fix argument order for for_each_string_list string_list: Fix argument order for print_string_list
2010-06-30Merge branch 'tr/rev-list-count'Junio C Hamano
* tr/rev-list-count: bash completion: Support "divergence from upstream" messages in __git_ps1 rev-list: introduce --count option Conflicts: contrib/completion/git-completion.bash
2010-06-27Merge branch 'jn/show-num-walks'Junio C Hamano
* jn/show-num-walks: DWIM 'git show -5' to 'git show --do-walk -5'
2010-06-27string_list: Fix argument order for string_list_appendJulian Phillips
Update the definition and callers of string_list_append to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-22Merge branch 'jc/rev-list-ancestry-path'Junio C Hamano
* jc/rev-list-ancestry-path: revision: Turn off history simplification in --ancestry-path mode revision: Fix typo in --ancestry-path error message Documentation/rev-list-options.txt: Explain --ancestry-path Documentation/rev-list-options.txt: Fix missing line in example history graph revision: --ancestry-path
2010-06-12rev-list: introduce --count optionThomas Rast
Add a --count option that, instead of actually listing the commits, merely counts them. This is mostly geared towards script use, and to this end it acts specially when used with --left-right: it outputs the left and right counts separately. Previously, scripts would have to run a shell loop or small inline script over to achieve the same. (Without --left-right, a simple |wc -l does the job.) Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>