summaryrefslogtreecommitdiff
path: root/log-tree.c
AgeCommit message (Collapse)AuthorFilesLines
2015-03-10log: decorate HEAD with branch nameLibravatar Junio C Hamano1-9/+68
Currently, log decorations do not indicate which branch is checked out and whether HEAD is detached. When branch foo is checked out, change the "HEAD, foo" part of the decorations to "HEAD -> foo". This serves to indicate both ref decorations (helped by the spacing) as well as their relationshsip. As a consequence, "HEAD" without any " -> " denotes a detached HEAD now. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-10Merge branch 'jc/decorate-leaky-separator-color' into HEADLibravatar Junio C Hamano1-0/+1
* jc/decorate-leaky-separator-color: log --decorate: do not leak "commit" color into the next item Documentation/config.txt: simplify boolean description in the syntax section Documentation/config.txt: describe 'color' value type in the "Values" section Documentation/config.txt: have a separate "Values" section Documentation/config.txt: describe the structure first and then meaning Documentation/config.txt: explain multi-valued variables once Documentation/config.txt: avoid unnecessary negation
2015-03-04log --decorate: do not leak "commit" color into the next itemLibravatar Junio C Hamano1-0/+1
In "git log --decorate", you would see the commit header like this: commit ... (HEAD, jc/decorate-leaky-separator-color) where "commit ... (" is painted in color.diff.commit, "HEAD" in color.decorate.head, ", " in color.diff.commit, the branch name in color.decorate.branch and then closing ")" in color.diff.commit. If you wanted to paint the HEAD and local branch name in the same color as the body text (perhaps because cyan and green are too faint on a black-on-white terminal to be readable), you would not want to have to say [color "decorate"] head = black branch = black because that you would not be able to reuse same configuration on a white-on-black terminal. You would naively expect [color "decorate"] head = normal branch = normal to work, but unfortunately it does not. It paints the string "HEAD" and the branch name in the same color as the opening parenthesis or comma between the decoration elements. This is because the code forgets to reset the color after printing the "prefix" in its own color. It theoretically is possible that some people were expecting and relying on that the attribute set as the "diff.commit" color, which is used to draw these opening parenthesis and inter-item comma, is inherited by the drawing of branch names, but it is not how the coloring works everywhere else. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-20Merge branch 'jn/parse-config-slot'Libravatar Junio C Hamano1-4/+3
Code cleanup. * jn/parse-config-slot: color_parse: do not mention variable name in error message pass config slots as pointers instead of offsets
2014-10-14color_parse: do not mention variable name in error messageLibravatar Jeff King1-2/+1
Originally the color-parsing function was used only for config variables. It made sense to pass the variable name so that the die() message could be something like: $ git -c color.branch.plain=bogus branch fatal: bad color value 'bogus' for variable 'color.branch.plain' These days we call it in other contexts, and the resulting error messages are a little confusing: $ git log --pretty='%C(bogus)' fatal: bad color value 'bogus' for variable '--pretty format' $ git config --get-color foo.bar bogus fatal: bad color value 'bogus' for variable 'command line' This patch teaches color_parse to complain only about the value, and then return an error code. Config callers can then propagate that up to the config parser, which mentions the variable name. Other callers can provide a custom message. After this patch these three cases now look like: $ git -c color.branch.plain=bogus branch error: invalid color value: bogus fatal: unable to parse 'color.branch.plain' from command-line config $ git log --pretty='%C(bogus)' error: invalid color value: bogus fatal: unable to parse --pretty format $ git config --get-color foo.bar bogus error: invalid color value: bogus fatal: unable to parse default color value Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-14pass config slots as pointers instead of offsetsLibravatar Jonathan Nieder1-2/+2
Many config-parsing helpers, like parse_branch_color_slot, take the name of a config variable and an offset to the "slot" name (e.g., "color.branch.plain" is passed along with "13" to effectively pass "plain"). This is leftover from the time that these functions would die() on error, and would want the full variable name for error reporting. These days they do not use the full variable name at all. Passing a single pointer to the slot name is more natural, and lets us more easily adjust the callers to use skip_prefix to avoid manually writing offset numbers. This is effectively a continuation of 9e1a5eb, which did the same for parse_diff_color_slot. This patch covers all of the remaining similar constructs. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Merge branch 'hj/pretty-naked-decoration'Libravatar Junio C Hamano1-8/+9
The pretty-format specifier "%d", which expanded to " (tagname)" for a tagged commit, gained a cousin "%D" that just gives the "tagname" without frills. * hj/pretty-naked-decoration: pretty: add %D format specifier
2014-09-18pretty: add %D format specifierLibravatar Harry Jeffery1-8/+9
Add a new format specifier, '%D' that is identical in behaviour to '%d', except that it does not include the ' (' prefix or ')' suffix provided by '%d'. Signed-off-by: Harry Jeffery <harry@exec64.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-11Merge branch 'jk/name-decoration-alloc'Libravatar Junio C Hamano1-15/+10
The API to allocate the structure to keep track of commit decoration was cumbersome to use, inviting lazy code to overallocate memory. * jk/name-decoration-alloc: log-tree: use FLEX_ARRAY in name_decoration log-tree: make name_decoration hash static log-tree: make add_name_decoration a public function
2014-08-27log-tree: use FLEX_ARRAY in name_decorationLibravatar Jeff King1-1/+1
We are already using the flex-array technique; let's annotate it with our usual FLEX_ARRAY macro. Besides being more readable, this is slightly more efficient on compilers that understand flex-arrays. Note that we need to bump the allocation in add_name_decoration, which did not explicitly add one byte for the NUL terminator of the string we are putting into the flex-array (it did not need to before, because the struct itself was over-allocated by one byte). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-26log-tree: make name_decoration hash staticLibravatar Jeff King1-3/+8
In the previous commit, we made add_name_decoration global so that adders would not have to access the hash directly. We now make the hash itself static so that callers _have_ to add through our function, making sure that all additions go through a single point. To do this, we have to add one more accessor function: a way to lookup entries in the hash. Since the only caller doesn't actually look at the returned value, but rather only asks whether there is a decoration or not, we could provide only a boolean "has_name_decoration". That would allow us to make "struct name_decoration" local to log-tree, as well. However, it's unlikely to cause any maintainability harm making the actual data public, and this interface is more flexible if we need to look at decorations from other parts of the code in the future. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-26log-tree: make add_name_decoration a public functionLibravatar Jeff King1-11/+1
The log-tree code keeps a "struct decoration" hash to show text decorations for each commit during log traversals. It makes this available to other files by providing global access to the hash. This can result in other code adding entries that do not conform to what log-tree expects. For example, the bisect code adds its own "dist" decorations to be shown. Originally the bisect code was correct, but when the name_decoration code grew a new field in eb3005e (commit.h: add 'type' to struct name_decoration, 2010-06-19), the bisect code was not updated. As a result, the log-tree code can access uninitialized memory and even segfault. We can fix this by making name_decoration's adding function public. If all callers use it, then any changes to struct initialization only need to happen in one place (and because the members come in as parameters, the compiler can notice a caller who does not supply enough information). As a bonus, this also means that the decoration hashes created by the bisect code will use less memory (previously we over-allocated space for the distance integer, but now we format it into a temporary buffer and copy it to the final flex-array). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-30pretty: make empty userformats truly emptyLibravatar Jeff King1-2/+3
If the user provides an empty format with "--format=", we end up putting in extra whitespace that the user cannot prevent. This comes from two places: 1. If the format is missing a terminating newline, we add one automatically. This makes sense for --format=%h, but not for a truly empty format. 2. We add an extra newline between the pretty-printed format and a diff or diffstat. If the format is empty, there's no point in doing so if there's nothing to separate. With this patch, one can get a diff with no other cruft out of "diff-tree --format= $commit". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21Merge branch 'cc/for-each-mergetag'Libravatar Junio C Hamano1-11/+4
* cc/for-each-mergetag: commit: add for_each_mergetag()
2014-07-16Merge branch 'zk/log-graph-showsig'Libravatar Junio C Hamano1-0/+1
The "--show-signature" option did not pay much attention to "--graph". * zk/log-graph-showsig: log: fix indentation for --graph --show-signature
2014-07-16Merge branch 'mg/fix-log-mergetag-color'Libravatar Junio C Hamano1-10/+11
* mg/fix-log-mergetag-color: log: correctly identify mergetag signature verification status
2014-07-10log: correctly identify mergetag signature verification statusLibravatar Michael J Gruber1-10/+11
A wrong '}' made our code record the results of mergetag signature verification incorrectly. Fix it. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-09log: fix indentation for --graph --show-signatureLibravatar Zoltan Klinger1-0/+1
The git log --graph --show-signature command incorrectly indents the gpg information about signed commits and merged signed tags. It does not follow the level of indentation of the current commit. Example of garbled output: $ git log --show-signature --graph * commit 258e0a237cb69aaa587b0a4fb528bb0316b1b776 |\ gpg: Signature made Mon, Jun 30, 2014 13:22:33 EDT using RSA key ID DA08 gpg: Good signature from "Jason Pyeron <jpye...@pdinc.us>" Merge: 727c355 1ca13ed | | Author: Jason Pyeron <jpye...@pdinc.us> | | Date: Mon Jun 30 13:22:29 2014 -0400 | | | | Merge of 1ca13ed2271d60ba9 branch - rebranding | | | * commit 1ca13ed2271d60ba93d40bcc8db17ced8545f172 | | gpg: Signature made Mon, Jun 23, 2014 9:45:47 EDT using RSA key ID DD37 gpg: Good signature from "Stephen Robert Guglielmo <s...@guglielmo.us>" gpg: aka "Stephen Robert Guglielmo <srguglie...@gmail.com>" Author: Stephen R Guglielmo <s...@guglielmo.us> | | Date: Mon Jun 23 09:45:27 2014 -0400 | | | | Minor URL updates In log-tree.c modify show_sig_lines() function to call graph_show_oneline() after each line of gpg information it has printed in order to preserve the level of indentation for the next output line. Reported-by: Jason Pyeron <jpyeron@pdinc.us> Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-07commit: add for_each_mergetag()Libravatar Christian Couder1-11/+4
In the same way as there is for_each_ref() to iterate on refs, for_each_mergetag() allows the caller to iterate on the mergetags of a given commit. Use it to rewrite show_mergetag() used in "git log". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13reuse cached commit buffer when parsing signaturesLibravatar Jeff King1-1/+1
When we call show_signature or show_mergetag, we read the commit object fresh via read_sha1_file and reparse its headers. However, in most cases we already have the object data available, attached to the "struct commit". This is partially laziness in dealing with the memory allocation issues, but partially defensive programming, in that we would always want to verify a clean version of the buffer (not one that might have been munged by other users of the commit). However, we do not currently ever munge the commit buffer, and not using the already-available buffer carries a fairly big performance penalty when we are looking at a large number of commits. Here are timings on linux.git: [baseline, no signatures] $ time git log >/dev/null real 0m4.902s user 0m4.784s sys 0m0.120s [before] $ time git log --show-signature >/dev/null real 0m14.735s user 0m9.964s sys 0m0.944s [after] $ time git log --show-signature >/dev/null real 0m9.981s user 0m5.260s sys 0m0.936s Note that our user CPU time drops almost in half, close to the non-signature case, but we do still spend more wall-clock and system time, presumably from dealing with gpg. An alternative to this is to note that most commits do not have signatures (less than 1% in this repo), yet we pay the re-parsing cost for every commit just to find out if it has a mergetag or signature. If we checked that when parsing the commit initially, we could avoid re-examining most commits later on. Even if we did pursue that direction, however, this would still speed up the cases where we _do_ have signatures. So it's probably worth doing either way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13commit: record buffer length in cacheLibravatar Jeff King1-1/+1
Most callsites which use the commit buffer try to use the cached version attached to the commit, rather than re-reading from disk. Unfortunately, that interface provides only a pointer to the NUL-terminated buffer, with no indication of the original length. For the most part, this doesn't matter. People do not put NULs in their commit messages, and the log code is happy to treat it all as a NUL-terminated string. However, some code paths do care. For example, when checking signatures, we want to be very careful that we verify all the bytes to avoid malicious trickery. This patch just adds an optional "size" out-pointer to get_commit_buffer and friends. The existing callers all pass NULL (there did not seem to be any obvious sites where we could avoid an immediate strlen() call, though perhaps with some further refactoring we could). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13use get_cached_commit_buffer where appropriateLibravatar Jeff King1-1/+1
Some call sites check commit->buffer to see whether we have a cached buffer, and if so, do some work with it. In the long run we may want to switch these code paths to make their decision on a different boolean flag (because checking the cache may get a little more expensive in the future). But for now, we can easily support them by converting the calls to use get_cached_commit_buffer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-03Merge branch 'nd/log-show-linear-break'Libravatar Junio C Hamano1-0/+4
Attempts to show where a single-strand-of-pearls break in "git log" output. * nd/log-show-linear-break: log: add --show-linear-break to help see non-linear history object.h: centralize object flag allocation
2014-03-25log: add --show-linear-break to help see non-linear historyLibravatar Nguyễn Thái Ngọc Duy1-0/+4
Option explanation is in rev-list-options.txt. The interaction with -z is left undecided. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-20rename read_replace_refs to check_replace_refsLibravatar Michael Haggerty1-1/+1
The semantics of this flag was changed in commit e1111cef23 inline lookup_replace_object() calls but wasn't renamed at the time to minimize code churn. Rename it now, and add a comment explaining its use. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-10Merge branch 'bc/log-decoration'Libravatar Junio C Hamano1-0/+2
"git log --decorate" did not handle a tag pointed by another tag nicely. * bc/log-decoration: log: properly handle decorations with chained tags
2013-12-20log: properly handle decorations with chained tagsLibravatar brian m. carlson1-0/+2
git log did not correctly handle decorations when a tag object referenced another tag object that was no longer a ref, such as when the second tag was deleted. The commit would not be decorated correctly because parse_object had not been called on the second tag and therefore its tagged field had not been filled in, resulting in none of the tags being associated with the relevant commit. Call parse_object to fill in this field if it is absent so that the chain of tags can be dereferenced and the commit can be properly decorated. Include tests as well to prevent future regressions. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-17Merge branch 'cc/starts-n-ends-with'Libravatar Junio C Hamano1-4/+4
Remove a few duplicate implementations of prefix/suffix comparison functions, and rename them to starts_with and ends_with. * cc/starts-n-ends-with: replace {pre,suf}fixcmp() with {starts,ends}_with() strbuf: introduce starts_with() and ends_with() builtin/remote: remove postfixcmp() and use suffixcmp() instead environment: normalize use of prefixcmp() by removing " != 0"
2013-12-05replace {pre,suf}fixcmp() with {starts,ends}_with()Libravatar Christian Couder1-4/+4
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05Merge branch 'jk/robustify-parse-commit'Libravatar Junio C Hamano1-3/+3
* jk/robustify-parse-commit: checkout: do not die when leaving broken detached HEAD use parse_commit_or_die instead of custom message use parse_commit_or_die instead of segfaulting assume parse_commit checks for NULL commit assume parse_commit checks commit->object.parsed log_tree_diff: die when we fail to parse a commit
2013-10-24log_tree_diff: die when we fail to parse a commitLibravatar Jeff King1-3/+3
We currently call parse_commit and then assume we can dereference the resulting "tree" struct field. If parsing failed, however, that field is NULL and we end up segfaulting. Instead of a segfault, let's print an error message and die a little more gracefully. Note that this should never happen in practice, but may happen in a corrupt repository. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-01log: use true parents for diff even when rewritingLibravatar Thomas Rast1-1/+1
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-15Merge branch 'jk/format-patch-from'Libravatar Junio C Hamano1-0/+2
"git format-patch" learned "--from[=whom]" option, which sets the "From: " header to the specified person (or the person who runs the command, if "=whom" part is missing) and move the original author information to an in-body From: header as necessary. * jk/format-patch-from: teach format-patch to place other authors into in-body "From" pretty.c: drop const-ness from pretty_print_context
2013-07-12Merge branch 'as/log-output-encoding-in-user-format'Libravatar Junio C Hamano1-0/+1
"log --format=" did not honor i18n.logoutputencoding configuration and this attempts to fix it. * as/log-output-encoding-in-user-format: t4205 (log-pretty-formats): avoid using `sed` t6006 (rev-list-format): add tests for "%b" and "%s" for the case i18n.commitEncoding is not set t4205, t6006, t7102: make functions better readable t4205 (log-pretty-formats): revert back single quotes t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1 t4205: replace .\+ with ..* in sed commands pretty: --format output should honor logOutputEncoding pretty: Add failing tests: --format output should honor logOutputEncoding t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs t7102 (reset): don't hardcode SHA-1 in expected outputs t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
2013-07-03teach format-patch to place other authors into in-body "From"Libravatar Jeff King1-0/+2
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-06-26pretty: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-0/+1
One can set an alias $ git config [--global] alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=local" to see the log as a pretty tree (like *gitk* but in a terminal). However, log messages written in an encoding i18n.commitEncoding which differs from terminal encoding are shown corrupted even when i18n.logOutputEncoding and terminal encoding are the same (e.g. log messages committed on a Cygwin box with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa). To simplify an example we can say the following two commands are expected to give the same output to a terminal: $ git log --oneline --no-color $ git log --pretty=format:'%h %s' However, the former pays attention to i18n.logOutputEncoding configuration, while the latter does not when it formats "%s". The same corruption is true for $ git diff --submodule=log and $ git rev-list --pretty=format:%s HEAD and $ git reset --hard This patch makes pretty --format honor logOutputEncoding when it formats log message. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02Merge branch 'tr/line-log'Libravatar Junio C Hamano1-0/+4
* 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-04-18pretty: share code between format_decoration and show_decorationsLibravatar Nguyễn Thái Ngọc Duy1-16/+32
This also adds color support to format_decorations() Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02Merge branch 'tr/log-tree-optim'Libravatar Junio C Hamano1-3/+10
Optimize "log" that shows the difference between the parent and the child. * tr/log-tree-optim: Avoid loading commits twice in log with diffs
2013-04-01Merge branch 'bc/append-signed-off-by'Libravatar Junio C Hamano1-86/+6
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-0/+4
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-28Avoid loading commits twice in log with diffsLibravatar Thomas Rast1-3/+10
If you run a log with diffs (such as -p, --raw, --stat etc.) the current code ends up loading many objects twice. For example, for 'log -3000 -p' my instrumentation said the objects loaded more than once are distributed as follows: 2008 blob 2103 commit 2678 tree Fixing blobs and trees will be harder, because those are really used within the diff engine and need some form of caching. However, fixing the commits is easy at least at the band-aid level. They are triggered by log_tree_diff() invoking diff_tree_sha1() on commits, which duly loads the specified object to dereference it to a tree. Since log_tree_diff() knows that it works with commits and they must have trees, we can simply pass through the trees. We add some parse_commit() calls. The ones for the parents are required; we do not know at this stage if they have been looked at. The one for the commit itself is pure paranoia, but has about the same cost as an assertion on commit->object.parsed. This has a quite dramatic effect on log --raw, though only a negligible impact on log -p: Test this tree HEAD -------------------------------------------------------------------- 4000.2: log --raw -3000 0.50(0.43+0.06) 0.54(0.46+0.06) +7.0%*** 4000.3: log -p -3000 2.34(2.20+0.13) 2.37(2.22+0.13) +1.2% -------------------------------------------------------------------- Significance hints: '.' 0.1 '*' 0.05 '**' 0.01 '***' 0.001 Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21Merge branch 'mg/gpg-interface-using-status'Libravatar Junio C Hamano1-15/+12
Call "gpg" using the right API when validating the signature on tags. * mg/gpg-interface-using-status: pretty: make %GK output the signing key for signed commits pretty: parse the gpg status lines rather than the output gpg_interface: allow to request status return log-tree: rely upon the check in the gpg_interface gpg-interface: check good signature in a reliable way
2013-02-14gpg_interface: allow to request status returnLibravatar Michael J Gruber1-2/+2
Currently, verify_signed_buffer() returns the user facing output only. Allow callers to request the status output also. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-14log-tree: rely upon the check in the gpg_interfaceLibravatar Michael J Gruber1-14/+11
It's just so much clearer. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-12Unify appending signoff in format-patch, commit and sequencerLibravatar Brandon Casey1-90/+1
There are two implementations of append_signoff in log-tree.c and sequencer.c, which do more or less the same thing. Unify on top of the sequencer.c implementation. Add a test in t4014 to demonstrate support for non-s-o-b elements in the commit footer provided by sequence.c:append_sob. Mark tests fixed as appropriate. [Commit message mostly stolen from Nguyễn Thái Ngọc Duy's original unification patch] Signed-off-by: Brandon Casey <bcasey@nvidia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-12format-patch: update append_signoff prototypeLibravatar Nguyễn Thái Ngọc Duy1-4/+13
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-21/+31
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>