aboutsummaryrefslogtreecommitdiff
path: root/revision.h
Commit message (Collapse)AuthorAge
* Merge branch 'cb/cherry-pick-rev-path-confusion'Junio C Hamano2012-04-27
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * cherry-pick: do not expect file argumentsClemens Buchacher2012-04-15
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Teach revision walking machinery to walk multiple times sequenciallyHeiko Voigt2012-03-30
|/ | | | | | | | | | | | | 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>
* log: --show-signatureJunio C Hamano2011-11-12
| | | | | | | | | | | | 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>
* Merge branch 'rs/pending'Junio C Hamano2011-10-13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * revision: add leak_pending flagRené Scharfe2011-10-03
| | | | | | | | | | | | | | | | | | | | | | 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>
| * revision: factor out add_pending_sha1René Scharfe2011-10-03
| | | | | | | | | | | | | | | | 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>
* | Merge branch 'jc/fetch-verify'Junio C Hamano2011-10-05
|\ \ | | | | | | | | | | | | | | | | | | * 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()
| * | rev-list --verify-objectJunio C Hamano2011-09-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jc/traverse-commit-list'Junio C Hamano2011-10-05
|\ \ \ | |/ / | | | | | | | | | | | | | | | * 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
| * | revision.c: add show_object_with_name() helper functionJunio C Hamano2011-08-22
| |/ | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'bk/ancestry-path'Junio C Hamano2011-10-05
|\ \ | |/ |/| | | | | | | | | | | * 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
| * revision: keep track of the end-user input from the command lineJunio C Hamano2011-08-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jk/format-patch-am'Junio C Hamano2011-05-31
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | format-patch: preserve subject newlines with -kJeff King2011-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jc/notes-batch-removal'Junio C Hamano2011-05-29
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | show: --ignore-missingJunio C Hamano2011-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Add log.abbrevCommit config variableJay Soffian2011-05-18
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | rev-list --count: separate count for --cherry-markMichael J Gruber2011-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'mg/rev-list-n-parents'Junio C Hamano2011-03-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | revision.c: introduce --min-parents and --max-parents optionsMichael J Gruber2011-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Merge branch 'mg/rev-list-one-side-only'Junio C Hamano2011-03-22
|\ \ \ \ | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | git-log: put space after commit markMichael J Gruber2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | revision.c: introduce --cherry-markMichael J Gruber2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | rev-list/log: factor out revision mark generationMichael J Gruber2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | revlist.c: introduce --left/right-only for unsymmetric pickingMichael J Gruber2011-02-21
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | struct rev_info: convert prune_data to struct pathspecNguyễn Thái Ngọc Duy2011-02-03
|/ / | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | setup_revisions(): Allow walking history in a submoduleHeiko Voigt2010-07-07
| | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'tr/rev-list-count'Junio C Hamano2010-06-30
|\ \ | |/ |/| | | | | | | | | | | | | * 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
| * rev-list: introduce --count optionThomas Rast2010-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | revision: --ancestry-pathJunio C Hamano2010-04-21
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "rev-list A..H" computes the set of commits that are ancestors of H, but excludes the ones that are ancestors of A. This is useful to see what happened to the history leading to H since A, in the sense that "what does H have that did not exist in A" (e.g. when you have a choice to update to H from A). x---x---A---B---C <-- topic / \ x---x---x---o---o---o---o---M---D---E---F---G <-- dev / \ x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master The result in the above example would be the commits marked with caps letters (except for A itself, of course), and the ones marked with 'o'. When you want to find out what commits in H are contaminated with the bug introduced by A and need fixing, however, you might want to view only the subset of "A..B" that are actually descendants of A, i.e. excluding the ones marked with 'o'. Introduce a new option --ancestry-path to compute this set with "rev-list --ancestry-path A..B". Note that in practice, you would build a fix immediately on top of A and "git branch --contains A" will give the names of branches that you would need to merge the fix into (i.e. topic, dev and master), so this may not be worth paying the extra cost of postprocessing. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'tr/notes-display'Junio C Hamano2010-03-24
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * tr/notes-display: git-notes(1): add a section about the meaning of history notes: track whether notes_trees were changed at all notes: add shorthand --ref to override GIT_NOTES_REF commit --amend: copy notes to the new commit rebase: support automatic notes copying notes: implement helpers needed for note copying during rewrite notes: implement 'git notes copy --stdin' rebase -i: invoke post-rewrite hook rebase: invoke post-rewrite hook commit --amend: invoke post-rewrite hook Documentation: document post-rewrite hook Support showing notes from more than one notes tree test-lib: unset GIT_NOTES_REF to stop it from influencing tests Conflicts: git-am.sh refs.c
| * Support showing notes from more than one notes treeThomas Rast2010-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this patch, you can set notes.displayRef to a glob that points at your favourite notes refs, e.g., [notes] displayRef = refs/notes/* Then git-log and friends will show notes from all trees. Thanks to Junio C Hamano for lots of feedback, which greatly influenced the design of the entire series and this commit in particular. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | show -c: show patch textJunio C Hamano2010-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, "show" defaulted to "show --cc" (dense combined patch), but asking for combined patch with "show -c" didn't turn the patch output format on; the placement of this logic in setup_revisions() dates back to cd2bdc5 (Common option parsing for "git log --diff" and friends, 2006-04-14). This unfortunately cannot be done as a trivial change of "if dense combined is asked, default to patch format" done in setup_revisions() to "if any combined is asked, default to patch format", as "diff-tree -c" needs to default to raw, while "diff-tree --cc" needs to default to patch, and they share the codepath. These command specific defaults are now handled in the new "tweak" callback that can be customized by individual command implementations. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | revision: introduce setup_revision_optJunio C Hamano2010-03-09
|/ | | | | | | | | | | So far the last parameter to setup_revisions() was to specify the default ref when the command line did not give any (typically "HEAD"). This changes it to take a pointer to a structure so that we can add other information without touching too many codepaths in later patches. There is no functionality change. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix "log" family not to be too agressive about showing notesJunio C Hamano2010-01-20
| | | | | | | | | | | | | | | | | Giving "Notes" information in the default output format of "log" and "show" is a sensible progress (the user has asked for it by having the notes), but for some commands (e.g. "format-patch") spewing notes into the formatted commit log message without being asked is too aggressive. Enable notes output only for "log", "show", "whatchanged" by default and only when the user didn't ask any specific --pretty/--format from the command line; users can explicitly override this default with --show-notes and --no-notes option. Parts of tests are taken from Jeff King's fix. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/log-stdin'Junio C Hamano2009-11-23
|\ | | | | | | | | | | | | | | | | | | | | | | * jc/log-stdin: Add trivial tests for --stdin option to log family Make --stdin option to "log" family read also pathspecs setup_revisions(): do not call get_pathspec() too early Teach --stdin option to "log" family read_revision_from_stdin(): use strbuf Conflicts: revision.c
| * Teach --stdin option to "log" familyJunio C Hamano2009-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the logic to read revs from standard input that rev-list knows about from it to revision machinery, so that all the users of setup_revisions() can feed the list of revs from the standard input when "--stdin" is used on the command line. Allow some users of the revision machinery that want different semantics from the "--stdin" option to disable it by setting an option in the rev_info structure. This also cleans up the kludge made to bundle.c via cut and paste. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add '--bisect' revision machinery argumentLinus Torvalds2009-10-28
|/ | | | | | | | | | | | | | | | | | | | | | I personally use "git bisect visualize" all the time when I bisect, but it turns out that that is not a very flexible model. Sometimes I want to do bisection based on all commits (no pathname limiting), but then visualize the current bisection tree with just a few pathnames because I _suspect_ those pathnames are involved in the problem but am not totally sure about them. And at other times, I want to use other revision parsing logic, none of which is available with "git bisect visualize". So this adds "--bisect" as a revision parsing argument, and as a result it just works with all the normal logging tools. So now I can just do gitk --bisect --simplify-by-decoration filename-here etc. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* improve reflog date/number heuristicJeff King2009-09-29
| | | | | | | | | | | | | | | | | | | | | | | When we show a reflog, we have two ways of naming the entry: by sequence number (e.g., HEAD@{0}) or by date (e.g., HEAD@{10 minutes ago}). There is no explicit option to set one or the other, but we guess based on whether or not the user has provided us with a date format, showing them the date version if they have done so, and the sequence number otherwise. This usually made sense if the use did something like "git log -g --date=relative". However, it didn't make much sense if the user set the date format using the log.date config variable; in that case, all of their reflogs would end up as dates. This patch records the source of the date format and only triggers the date-based view if --date= was given on the command line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Merge branch 'as/maint-graph-interesting-fix'Junio C Hamano2009-08-27
|\ | | | | | | | | | | * as/maint-graph-interesting-fix: Add tests for rev-list --graph with options that simplify history graph API: fix bug in graph_is_interesting()
| * graph API: fix bug in graph_is_interesting()Adam Simpkins2009-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, graph_is_interesting() did not behave quite the same way as the code in get_revision(). As a result, it would sometimes think commits were uninteresting, even though get_revision() would return them. This resulted in incorrect lines in the graph output. This change creates a get_commit_action() function, which graph_is_interesting() and simplify_commit() both now use to determine if a commit will be shown. It is identical to the old simplify_commit() behavior, except that it never calls rewrite_parents(). This problem was reported by Santi Béjar. The following command would exhibit the problem before, but now works correctly: git log --graph --simplify-by-decoration --oneline v1.6.3.3 Previously git graph did not display the output for this command correctly between f29ac4f and 66996ec, among other places. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-log: allow --decorate[=short|full]Lars Hjemli2009-08-18
|/ | | | | | | | | | | | | | | Commit de435ac0 changed the behavior of --decorate from printing the full ref (e.g., "refs/heads/master") to a shorter, more human-readable version (e.g., just "master"). While this is nice for human readers, external tools using the output from "git log" may prefer the full version. This patch introduces an extension to --decorate to allow the caller to specify either the short or the full versions. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git log: add '--merges' flag to match '--no-merges'Linus Torvalds2009-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I do various statistics on git, and one of the things I look at is merges, because they are often interesting events to count ("how many merges vs how much 'real development'" kind of statistics). And you can do it with some fairly straightforward scripting, ie git rev-list --parents HEAD | grep ' .* ' | git diff-tree --always -s --pretty=oneline --stdin | less -S will do it. But I finally got irritated with the fact that we can skip merges with '--no-merges', but we can't do the trivial reverse operation. So this just adds a '--merges' flag that _only_ shows merges. Now you can do the above with just a git log --merges --pretty=oneline which is a lot simpler. It also means that we automatically get a lot of statistics for free, eg git shortlog -ns --merges does exactly what you'd want it to do. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Clean up and simplify rev_compare_tree()Linus Torvalds2009-06-03
| | | | | | | | | | | | | | | | | | This simplifies the logic of rev_compare_tree() by removing a special case. It does so by turning the special case of finding a diff to be "all new files" into a more generic case of "all new" vs "all removed" vs "mixed changes", so now the code is actually more powerful and more generic, and the added symmetry actually makes it simpler too. This makes no changes to any existing behavior, but apart from the simplification it does make it possible to some day care about whether all changes were just deletions if we want to. Which we may well want to for merge handling. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'lt/pack-object-memuse'Junio C Hamano2009-04-18
|\ | | | | | | | | | | | | | | | | | | | | | | | | * lt/pack-object-memuse: show_object(): push path_name() call further down process_{tree,blob}: show objects without buffering Conflicts: builtin-pack-objects.c builtin-rev-list.c list-objects.c list-objects.h upload-pack.c
| * show_object(): push path_name() call further downLinus Torvalds2009-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, pushing the "path_name()" call _into_ the show() function would seem to allow - more clarity into who "owns" the name (ie now when we free the name in the show_object callback, it's because we generated it ourselves by calling path_name()) - not calling path_name() at all, either because we don't care about the name in the first place, or because we are actually happy walking the linked list of "struct name_path *" and the last component. Now, I didn't do that latter optimization, because it would require some more coding, but especially looking at "builtin-pack-objects.c", we really don't even want the whole pathname, we really would be better off with the list of path components. Why? We use that name for two things: - add_preferred_base_object(), which actually _wants_ to traverse the path, and now does it by looking for '/' characters! - for 'name_hash()', which only cares about the last 16 characters of a name, so again, generating the full name seems to be just unnecessary work. Anyway, so I didn't look any closer at those things, but it did convince me that the "show_object()" calling convention was crazy, and we're actually better off doing _less_ in list-objects.c, and giving people access to the internal data structures so that they can decide whether they want to generate a path-name or not. This patch does that, and then for people who did use the name (even if they might do something more clever in the future), it just does the straightforward "name = path_name(path, component); .. free(name);" thing. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * process_{tree,blob}: show objects without bufferingLinus Torvalds2009-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here's a less trivial thing, and slightly more dubious one. I was looking at that "struct object_array objects", and wondering why we do that. I have honestly totally forgotten. Why not just call the "show()" function as we encounter the objects? Rather than add the objects to the object_array, and then at the very end going through the array and doing a 'show' on all, just do things more incrementally. Now, there are possible downsides to this: - the "buffer using object_array" _can_ in theory result in at least better I-cache usage (two tight loops rather than one more spread out one). I don't think this is a real issue, but in theory.. - this _does_ change the order of the objects printed. Instead of doing a "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop over the commits (which puts all the root trees _first_ in the object list, this patch just adds them to the list of pending objects, and then we'll traverse them in that order (and thus show each root tree object together with the objects we discover under it) I _think_ the new ordering actually makes more sense, but the object ordering is actually a subtle thing when it comes to packing efficiency, so any change in order is going to have implications for packing. Good or bad, I dunno. - There may be some reason why we did it that odd way with the object array, that I have simply forgotten. Anyway, now that we don't buffer up the objects before showing them that may actually result in lower memory usage during that whole traverse_commit_list() phase. This is seriously not very deeply tested. It makes sense to me, it seems to pass all the tests, it looks ok, but... Does anybody remember why we did that "object_array" thing? It used to be an "object_list" a long long time ago, but got changed into the array due to better memory usage patterns (those linked lists of obejcts are horrible from a memory allocation standpoint). But I wonder why we didn't do this back then. Maybe there's a reason for it. Or maybe there _used_ to be a reason, and no longer is. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'sb/format-patch-patchname'Junio C Hamano2009-04-06
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * sb/format-patch-patchname: format_sanitized_subject: Don't trim past initial length of strbuf log-tree: fix patch filename computation in "git format-patch" format-patch: --numbered-files and --stdout aren't mutually exclusive format-patch: --attach/inline uses filename instead of SHA1 format-patch: move get_patch_filename() into log-tree format-patch: pass a commit to reopen_stdout() format-patch: construct patch filename in one function pretty.c: add %f format specifier to format_commit_message()
| * | format-patch: --attach/inline uses filename instead of SHA1Stephen Boyd2009-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when format-patch is used with --attach or --inline the patch attachment has the SHA1 of the commit for its filename. This replaces the SHA1 with the filename used by format-patch when outputting to files. Fix tests relying on the SHA1 output and add a test showing how the --suffix option affects the attachment filename output. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>