summaryrefslogtreecommitdiff
path: root/revision.h
AgeCommit message (Collapse)AuthorFilesLines
2013-12-05Merge branch 'jc/ref-excludes'Libravatar Junio C Hamano1-0/+8
People often wished a way to tell "git log --branches" (and "git log --remotes --not --branches") to exclude some local branches from the expansion of "--branches" (similarly for "--tags", "--all" and "--glob=<pattern>"). Now they have one. * jc/ref-excludes: rev-parse: introduce --exclude=<glob> to tame wildcards rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API rev-list --exclude: tests document --exclude option revision: introduce --exclude=<glob> to tame wildcards
2013-11-01rev-list --exclude: export add/clear-ref-exclusion and ref-excluded APILibravatar Junio C Hamano1-0/+5
... while updating their function signature. To be squashed into the initial patch to rev-list. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-31revision: add missing includeLibravatar Felipe Contreras1-0/+1
Otherwise we might not have 'struct diff_options'. [jc: needs a matching follow-up patch to remove inclusion of diff.h from *.c files that do not themselves use anything from diff.h] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-30revision: introduce --exclude=<glob> to tame wildcardsLibravatar Junio C Hamano1-0/+3
People often find "git log --branches" etc. that includes _all_ branches is cumbersome to use when they want to grab most but except some. The same applies to --tags, --all and --glob. Teach the revision machinery to remember patterns, and then upon the next such a globbing option, exclude those that match the pattern. With this, I can view only my integration branches (e.g. maint, master, etc.) without topic branches, which are named after two letters from primary authors' names, slash and topic name. git rev-list --no-walk --exclude=??/* --branches | git name-rev --refs refs/heads/* --stdin This one shows things reachable from local and remote branches that have not been merged to the integration branches. git log --remotes --branches --not --exclude=??/* --branches It may be a bit rough around the edges, in that the pattern to give the exclude option depends on what globbing option follows. In these examples, the pattern "??/*" is used, not "refs/heads/??/*", because the globbing option that follows the -"-exclude=<pattern>" is "--branches". As each use of globbing option resets previously set "--exclude", this may not be such a bad thing, though. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-01log: use true parents for diff even when rewritingLibravatar Thomas Rast1-0/+20
When using pathspec filtering in combination with diff-based log output, parent simplification happens before the diff is computed. The diff is therefore against the *simplified* parents. This works okay, arguably by accident, in the normal case: simplification reduces to one parent as long as the commit is TREESAME to it. So the simplified parent of any given commit must have the same tree contents on the filtered paths as its true (unfiltered) parent. However, --full-diff breaks this guarantee, and indeed gives pretty spectacular results when comparing the output of git log --graph --stat ... git log --graph --full-diff --stat ... (--graph internally kicks in parent simplification, much like --parents). To fix it, store a copy of the parent list before simplification (in a slab) whenever --full-diff is in effect. Then use the stored parents instead of the simplified ones in the commit display code paths. The latter do not actually check for --full-diff to avoid duplicated code; they just grab the original parents if save_parents() has not been called for this revision walk. For ordinary commits it should be obvious that this is the right thing to do. Merge commits are a bit subtle. Observe that with default simplification, merge simplification is an all-or-nothing decision: either the merge is TREESAME to one parent and disappears, or it is different from all parents and the parent list remains intact. Redundant parents are not pruned, so the existing code also shows them as a merge. So if we do show a merge commit, the parent list just consists of the rewrite result on each parent. Running, e.g., --cc on this in --full-diff mode is not very useful: if any commits were skipped, some hunks will disagree with all sides of the merge (with one side, because commits were skipped; with the others, because they didn't have those changes in the first place). This triggers --cc showing these hunks spuriously. Therefore I believe that even for merge commits it is better to show the diffs wrt. the original parents. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03teach format-patch to place other authors into in-body "From"Libravatar Jeff King1-0/+1
Format-patch generates emails with the "From" address set to the author of each patch. If you are going to send the emails, however, you would want to replace the author identity with yours (if they are not the same), and bump the author identity to an in-body header. Normally this is handled by git-send-email, which does the transformation before sending out the emails. However, some workflows may not use send-email (e.g., imap-send, or a custom script which feeds the mbox to a non-git MUA). They could each implement this feature themselves, but getting it right is non-trivial (one must canonicalize the identities by reversing any RFC2047 encoding or RFC822 quoting of the headers, which has caused many bugs in send-email over the years). This patch takes a different approach: it teaches format-patch a "--from" option which handles the ident check and in-body header while it is writing out the email. It's much simpler to do at this level (because we haven't done any quoting yet), and any workflow based on format-patch can easily turn it on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-01Merge branch 'jc/topo-author-date-sort'Libravatar Junio C Hamano1-1/+5
"git log" learned the "--author-date-order" option, with which the output is topologically sorted and commits in parallel histories are shown intermixed together based on the author timestamp. * jc/topo-author-date-sort: t6003: add --author-date-order test topology tests: teach a helper to set author dates as well t6003: add --date-order test topology tests: teach a helper to take abbreviated timestamps t/lib-t6000: style fixes log: --author-date-order sort-in-topological-order: use prio-queue prio-queue: priority queue of pointers to structs toposort: rename "lifo" field
2013-06-14Merge branch 'mh/reflife'Libravatar Junio C Hamano1-11/+21
Define memory ownership and lifetime rules for what for-each-ref feeds to its callbacks (in short, "you do not own it, so make a copy if you want to keep it"). * mh/reflife: (25 commits) refs: document the lifetime of the args passed to each_ref_fn register_ref(): make a copy of the bad reference SHA-1 exclude_existing(): set existing_refs.strdup_strings string_list_add_refs_by_glob(): add a comment about memory management string_list_add_one_ref(): rename first parameter to "refname" show_head_ref(): rename first parameter to "refname" show_head_ref(): do not shadow name of argument add_existing(): do not retain a reference to sha1 do_fetch(): clean up existing_refs before exiting do_fetch(): reduce scope of peer_item object_array_entry: fix memory handling of the name field find_first_merges(): remove unnecessary code find_first_merges(): initialize merges variable using initializer fsck: don't put a void*-shaped peg in a char*-shaped hole object_array_remove_duplicates(): rewrite to reduce copying revision: use object_array_filter() in implementation of gc_boundary() object_array: add function object_array_filter() revision: split some overly-long lines cmd_diff(): make it obvious which cases are exclusive of each other cmd_diff(): rename local variable "list" -> "entry" ...
2013-06-14Merge branch 'kb/full-history-compute-treesame-carefully-2'Libravatar Junio C Hamano1-1/+3
Major update to the revision traversal logic to improve culling of irrelevant parents while traversing a mergy history. * kb/full-history-compute-treesame-carefully-2: revision.c: make default history consider bottom commits revision.c: don't show all merges for --parents revision.c: discount side branches when computing TREESAME revision.c: add BOTTOM flag for commits simplify-merges: drop merge from irrelevant side branch simplify-merges: never remove all TREESAME parents t6012: update test for tweaked full-history traversal revision.c: Make --full-history consider more merges Documentation: avoid "uninteresting" rev-list-options.txt: correct TREESAME for P t6111: add parents to tests t6111: allow checking the parents as well t6111: new TREESAME test set t6019: test file dropped in -s ours merge decorate.c: compact table when growing
2013-06-11toposort: rename "lifo" fieldLibravatar Junio C Hamano1-1/+5
The primary invariant of sort_in_topological_order() is that a parent commit is not emitted until all children of it are. When traversing a forked history like this with "git log C E": A----B----C \ D----E we ensure that A is emitted after all of B, C, D, and E are done, B has to wait until C is done, and D has to wait until E is done. In some applications, however, we would further want to control how these child commits B, C, D and E on two parallel ancestry chains are shown. Most of the time, we would want to see C and B emitted together, and then E and D, and finally A (i.e. the --topo-order output). The "lifo" parameter of the sort_in_topological_order() function is used to control this behaviour. We start the traversal by knowing two commits, C and E. While keeping in mind that we also need to inspect E later, we pick C first to inspect, and we notice and record that B needs to be inspected. By structuring the "work to be done" set as a LIFO stack, we ensure that B is inspected next, before other in-flight commits we had known that we will need to inspect, e.g. E. When showing in --date-order, we would want to see commits ordered by timestamps, i.e. show C, E, B and D in this order before showing A, possibly mixing commits from two parallel histories together. When "lifo" parameter is set to false, the function keeps the "work to be done" set sorted in the date order to realize this semantics. After inspecting C, we add B to the "work to be done" set, but the next commit we inspect from the set is E which is newer than B. The name "lifo", however, is too strongly tied to the way how the function implements its behaviour, and does not describe what the behaviour _means_. Replace this field with an enum rev_sort_order, with two possible values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and update the existing code. The mechanical replacement rule is: "lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE" "lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER" Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02Merge branch 'tr/line-log'Libravatar Junio C Hamano1-1/+15
* tr/line-log: git-log(1): remove --full-line-diff description line-log: fix documentation formatting log -L: improve comments in process_all_files() log -L: store the path instead of a diff_filespec log -L: test merge of parallel modify/rename t4211: pass -M to 'git log -M -L...' test log -L: fix overlapping input ranges log -L: check range set invariants when we look it up Speed up log -L... -M log -L: :pattern:file syntax to find by funcname Implement line-history search (git log -L) Export rewrite_parents() for 'log -L' Refactor parse_loc
2013-05-28revision: split some overly-long linesLibravatar Michael Haggerty1-11/+21
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: add BOTTOM flag for commitsLibravatar Kevin Bracey1-1/+2
When performing edge-based operations on the revision graph, it can be useful to be able to identify the INTERESTING graph's connection(s) to the bottom commit(s) specified by the user. Conceptually when the user specifies "A..B" (== B ^A), they are asking for the history from A to B. The first connection from A onto the INTERESTING graph is part of that history, and should be considered. If we consider only INTERESTING nodes and their connections, then we're really only considering the history from A's immediate descendants to B. This patch does not change behaviour, but adds a new BOTTOM flag to indicate the bottom commits specified by the user, ready to be used by following patches. We immediately use the BOTTOM flag to return collect_bottom_commits() to its original approach of examining the pending commit list rather than the command line. This will ensure alignment of the definition of "bottom" with future patches. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: Make --full-history consider more mergesLibravatar Kevin Bracey1-0/+1
History simplification previously always treated merges as TREESAME if they were TREESAME to any parent. While this was consistent with the default behaviour, this could be extremely unhelpful when searching detailed history, and could not be overridden. For example, if a merge had ignored a change, as if by "-s ours", then: git log -m -p --full-history -Schange file would successfully locate "change"'s addition but would not locate the merge that resolved against it. Futher, simplify_merges could drop the actual parent that a commit was TREESAME to, leaving it as a normal commit marked TREESAME that isn't actually TREESAME to its remaining parent. Now redefine a commit's TREESAME flag to be true only if a commit is TREESAME to _all_ of its parents. This doesn't affect either the default simplify_history behaviour (because partially TREESAME merges are turned into normal commits), or full-history with parent rewriting (because all merges are output). But it does affect other modes. The clearest difference is that --full-history will show more merges - sufficient to ensure that -m -p --full-history log searches can really explain every change to the file, including those changes' ultimate fate in merges. Also modify simplify_merges to recalculate TREESAME after removing a parent. This is achieved by storing per-parent TREESAME flags on the initial scan, so the combined flag can be easily recomputed. This fixes some t6111 failures, but creates a couple of new ones - we are now showing some merges that don't need to be shown. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: treat A...B merge bases as if manually specifiedLibravatar Kevin Bracey1-0/+1
The documentation assures users that "A...B" is defined as "A B --not $(git merge-base --all A B)". This wasn't in fact quite true, because the calculated merge bases were not sent to add_rev_cmdline(). The main effect of this was that although git rev-list --ancestry-path A B --not $(git merge-base --all A B) worked, the simpler form git rev-list --ancestry-path A...B failed with a "no bottom commits" error. Other potential users of bottom commits could also be affected by this problem, if they examine revs->cmdline_info; I came across the issue in my proposed history traversal refinements series. So ensure that the calculated merge bases are sent to add_rev_cmdline(), flagged with new 'whence' enum value REV_CMD_MERGE_BASE. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'bc/append-signed-off-by'Libravatar Junio C Hamano1-1/+1
Consolidate codepaths that inspect log-message-to-be and decide to add a new Signed-off-by line in various commands. * bc/append-signed-off-by: git-commit: populate the edit buffer with 2 blank lines before s-o-b Unify appending signoff in format-patch, commit and sequencer format-patch: update append_signoff prototype t4014: more tests about appending s-o-b lines sequencer.c: teach append_signoff to avoid adding a duplicate newline sequencer.c: teach append_signoff how to detect duplicate s-o-b sequencer.c: always separate "(cherry picked from" from commit body sequencer.c: require a conforming footer to be preceded by a blank line sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer t/t3511: add some tests of 'cherry-pick -s' functionality t/test-lib-functions.sh: allow to specify the tag name to test_commit commit, cherry-pick -s: remove broken support for multiline rfc2822 fields sequencer.c: rework search for start of footer to improve clarity
2013-03-28Implement line-history search (git log -L)Libravatar Thomas Rast1-1/+5
This is a rewrite of much of Bo's work, mainly in an effort to split it into smaller, easier to understand routines. The algorithm is built around the struct range_set, which encodes a series of line ranges as intervals [a,b). This is used in two contexts: * A set of lines we are tracking (which will change as we dig through history). * To encode diffs, as pairs of ranges. The main routine is range_set_map_across_diff(). It processes the diff between a commit C and some parent P. It determines which diff hunks are relevant to the ranges tracked in C, and computes the new ranges for P. The algorithm is then simply to process history in topological order from newest to oldest, computing ranges and (partial) diffs. At branch points, we need to merge the ranges we are watching. We will find that many commits do not affect the chosen ranges, and mark them TREESAME (in addition to those already filtered by pathspec limiting). Another pass of history simplification then gets rid of such commits. This is wired as an extra filtering pass in the log machinery. This currently only reduces code duplication, but should allow for other simplifications and options to be used. Finally, we hook a diff printer into the output chain. Ideally we would wire directly into the diff logic, to optionally use features like word diff. However, that will require some major reworking of the diff chain, so we completely replace the output with our own diff for now. As this was a GSoC project, and has quite some history by now, many people have helped. In no particular order, thanks go to Jakub Narebski <jnareb@gmail.com> Jens Lehmann <Jens.Lehmann@web.de> Jonathan Nieder <jrnieder@gmail.com> Junio C Hamano <gitster@pobox.com> Ramsay Jones <ramsay@ramsay1.demon.co.uk> Will Palmer <wmpalmer@gmail.com> Apologies to everyone I forgot. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28Export rewrite_parents() for 'log -L'Libravatar Bo Yang1-0/+10
The function rewrite_one is used to rewrite a single parent of the current commit, and is used by rewrite_parents to rewrite all the parents. Decouple the dependence between them by making rewrite_one a callback function that is passed to rewrite_parents. Then export rewrite_parents for reuse by the line history browser. We will use this function in line-log.c. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-12format-patch: update append_signoff prototypeLibravatar Nguyễn Thái Ngọc Duy1-1/+1
This is a preparation step for merging with append_signoff from sequencer.c Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Brandon Casey <bcasey@nvidia.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-20Merge branch 'ap/log-mailmap'Libravatar Junio C Hamano1-0/+1
Teach commands in the "log" family to optionally pay attention to the mailmap. * ap/log-mailmap: log --use-mailmap: optimize for cases without --author/--committer search log: add log.mailmap configuration option log: grep author/committer using mailmap test: add test for --use-mailmap option log: add --use-mailmap option pretty: use mailmap to display username and email mailmap: add mailmap structure to rev_info and pp mailmap: simplify map_user() interface mailmap: remove email copy and length limitation Use split_ident_line to parse author and committer string-list: allow case-insensitive string list
2013-01-11Merge branch 'jc/format-patch-reroll'Libravatar Junio C Hamano1-0/+1
Teach "format-patch" to prefix v4- to its output files for the fourth iteration of a patch series, to make it easier for the submitter to keep separate copies for iterations. * jc/format-patch-reroll: format-patch: give --reroll-count a short synonym -v format-patch: document and test --reroll-count format-patch: add --reroll-count=$N option get_patch_filename(): split into two functions get_patch_filename(): drop "just-numbers" hack get_patch_filename(): simplify function signature builtin/log.c: stop using global patch_suffix builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter() builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
2013-01-10mailmap: add mailmap structure to rev_info and ppLibravatar Antoine Pelisse1-0/+1
Pass a mailmap from rev_info to pretty_print_context to so that the pretty printer can use rewritten name and email address when showing commits. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-22format-patch: add --reroll-count=$N optionLibravatar Junio C Hamano1-0/+1
The --reroll-count=$N option, when given a positive integer: - Adds " v$N" to the subject prefix specified. As the default subject prefix string is "PATCH", --reroll-count=2 makes it "PATCH v2". - Prefixes "v$N-" to the names used for output files. The cover letter, whose name is usually 0000-cover-letter.patch, becomes v2-0000-cover-letter.patch when given --reroll-count=2. This allows users to use the same --output-directory for multiple iterations of the same series, without letting the output for a newer round overwrite output files from the earlier rounds. The user can incorporate materials from earlier rounds to update the newly minted iteration, and use "send-email v2-*.patch" to send out the patches belonging to the second iteration easily. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-17format-patch --notes: show notes after three-dashesLibravatar Junio C Hamano1-0/+1
When inserting the note after the commit log message to format-patch output, add three dashes before the note. Record the fact that we did so in the rev_info and omit showing duplicated three dashes in the usual codepath that is used when notes are not being shown. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'mz/cherry-pick-cmdline-order'Libravatar Junio C Hamano1-1/+5
"git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. * mz/cherry-pick-cmdline-order: cherry-pick/revert: respect order of revisions to pick demonstrate broken 'git cherry-pick three one two' teach log --no-walk=unsorted, which avoids sorting
2012-08-30teach log --no-walk=unsorted, which avoids sortingLibravatar Martin von Zweigbergk1-1/+5
When 'git log' is passed the --no-walk option, no revision walk takes place, naturally. Perhaps somewhat surprisingly, however, the provided revisions still get sorted by commit date. So e.g 'git log --no-walk HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result (unless the two revisions share the commit date, in which case they will retain the order given on the command line). As the commit that introduced --no-walk (8e64006 (Teach revision machinery about --no-walk, 2007-07-24)) points out, the sorting is intentional, to allow things like git log --abbrev-commit --pretty=oneline --decorate --all --no-walk to show all refs in order by commit date. But there are also other cases where the sorting is not wanted, such as <command producing revisions in order> | git log --oneline --no-walk --stdin To accomodate both cases, leave the decision of whether or not to sort up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting to 'sorted' for backward-compatibility reasons. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Merge branch 'jc/sha1-name-more'Libravatar Junio C Hamano1-1/+4
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...
2012-07-09revision.c: the "log" family, except for "show", takes committishLibravatar Junio C Hamano1-0/+2
Add a field to setup_revision_opt structure and allow these callers to tell the setup_revisions command parsing machinery that short SHA1 it encounters are meant to name committish. This step does not go all the way to connect the setup_revisions() to sha1_name.c yet. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09revision.c: allow handle_revision_arg() to take other flagsLibravatar Junio C Hamano1-1/+2
The existing "cant_be_filename" that tells the function that the caller knows the arg is not a path (hence it does not have to be checked for absense of the file whose name matches it) is made into a bit in the flag word. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27Merge branch 'cb/cherry-pick-rev-path-confusion'Libravatar Junio C Hamano1-0/+1
The command line parser choked "git cherry-pick $name" when $name can be both revision name and a pathname, even though $name can never be a path in the context of the command. The issue the patch addresses is real, but the way it is implemented felt unnecessarily invasive a bit. It may be cleaner for this caller to add the "--" to the end of the argv_array it passes to setup_revisions(). By Clemens Buchacher * cb/cherry-pick-rev-path-confusion: cherry-pick: do not expect file arguments
2012-04-15cherry-pick: do not expect file argumentsLibravatar Clemens Buchacher1-0/+1
If a commit-ish passed to cherry-pick or revert happens to have a file of the same name, git complains that the argument is ambiguous and advises to use '--'. To make things worse, the '--' argument is removed by parse_options, und so passing '--' has no effect. Instead, always interpret cherry-pick/revert arguments as revisions. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-30Teach revision walking machinery to walk multiple times sequenciallyLibravatar Heiko Voigt1-0/+1
Previously it was not possible to iterate revisions twice using the revision walking api. We add a reset_revision_walk() which clears the used flags. This allows us to do multiple sequencial revision walks. We add the appropriate calls to the existing submodule machinery doing revision walks. This is done to avoid surprises if future code wants to call these functions more than once during the processes lifetime. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-12log: --show-signatureLibravatar Junio C Hamano1-0/+1
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-0/+2
* 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-05Merge branch 'jc/fetch-verify'Libravatar Junio C Hamano1-0/+1
* 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/+2
* 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-0/+20
* 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-0/+1
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-0/+1
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-01rev-list --verify-objectLibravatar Junio C Hamano1-0/+1
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: keep track of the end-user input from the command lineLibravatar Junio C Hamano1-0/+20
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: add show_object_with_name() helper functionLibravatar Junio C Hamano1-0/+2
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-31Merge branch 'jk/format-patch-am'Libravatar Junio C Hamano1-1/+2
* jk/format-patch-am: format-patch: preserve subject newlines with -k clean up calling conventions for pretty.c functions pretty: add pp_commit_easy function for simple callers mailinfo: always clean up rfc822 header folding t: test subject handling in format-patch / am pipeline Conflicts: builtin/branch.c builtin/log.c commit.h
2011-05-29Merge branch 'jc/notes-batch-removal'Libravatar Junio C Hamano1-1/+2
* 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-26format-patch: preserve subject newlines with -kLibravatar Jeff King1-1/+2
In older versions of git, we used rfc822 header folding to indicate that the original subject line had multiple lines in it. But since a1f6baa (format-patch: wrap long header lines, 2011-02-23), we now use header folding whenever there is a long line. This means that "git am" cannot trust header folding as a sign from format-patch that newlines should be preserved. Instead, format-patch needs to signal more explicitly that the newlines are significant. This patch does so by rfc2047-encoding the newlines in the subject line. No changes are needed on the "git am" end; it already decodes the newlines properly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-19show: --ignore-missingLibravatar Junio C Hamano1-1/+2
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/+1
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-04-26rev-list --count: separate count for --cherry-markLibravatar Michael J Gruber1-0/+1
When --count is used with --cherry-mark, omit the patch equivalent commits from the count for left and right commits and print the count of equivalent commits separately. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-26Merge branch 'mg/rev-list-n-parents'Libravatar Junio C Hamano1-2/+2
* 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-2/+2
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>