summaryrefslogtreecommitdiff
path: root/pretty.c
AgeCommit message (Collapse)AuthorFilesLines
2016-07-11Merge branch 'nd/graph-width-padded' into maintLibravatar Junio C Hamano1-1/+8
"log --graph --format=" learned that "%>|(N)" specifies the width relative to the terminal's left edge, not relative to the area to draw text that is to the right of the ancestry-graph section. It also now accepts negative N that means the column limit is relative to the right border. * nd/graph-width-padded: pretty.c: support <direction>|(<negative number>) forms pretty: pass graph width to pretty formatting for use in '%>|(N)'
2016-06-27Merge branch 'et/pretty-format-c-auto' into maintLibravatar Junio C Hamano1-1/+1
The commands in `git log` family take %C(auto) in a custom format string. This unconditionally turned the color on, ignoring --no-color or with --color=auto when the output is not connected to a tty; this was corrected to make the format truly behave as "auto". * et/pretty-format-c-auto: format_commit_message: honor `color=auto` for `%C(auto)`
2016-06-16pretty.c: support <direction>|(<negative number>) formsLibravatar Nguyễn Thái Ngọc Duy1-1/+7
%>|(num), %><|(num) and %<|(num), where num is a positive number, sets a fixed column from the screen's left border. There is no way for us to specifiy a column relative to the right border, which is useful when you want to make use of all terminal space (on big screens). Use negative num for that. Inspired by Go's array syntax (*). (*) I know Python has this first (or before Go, at least) but the idea didn't occur to me until I learned Go. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty: pass graph width to pretty formatting for use in '%>|(N)'Libravatar Josef Kufner1-0/+1
Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all commit hashes align at 20th column from the edge of the terminal, not from the edge of the graph. Signed-off-by: Josef Kufner <josef@kufner.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-27format_commit_message: honor `color=auto` for `%C(auto)`Libravatar Edward Thomson1-1/+1
git-log(1) documents that when specifying the `%C(auto)` format placeholder will "turn on auto coloring on the next %placeholders until the color is switched again." However, when `%C(auto)` is used, the present implementation will turn colors on unconditionally (even if the color configuration is turned off for the current context - for example, `--no-color` was specified or the color is `auto` and the output is not a tty). Update `format_commit_one` to examine the current context when a format string of `%C(auto)` is specified, which ensures that we will not unconditionally write colors. This brings that behavior in line with the behavior of `%C(auto,<colorname>)`, and allows the user the ability to specify that color should be displayed only when the output is a tty. Additionally, add a test for `%C(auto)` and update the existing tests for `%C(auto,...)` as they were misidentified as being applicable to `%C(auto)`. Tests from Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30pretty: allow tweaking tabwidth in --expand-tabsLibravatar Junio C Hamano1-7/+8
When the local convention of the project is to use tab width that is not 8, it may make sense to allow "git log --expand-tabs=<n>" to tweak the output to match it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30pretty: enable --expand-tabs by default for selected pretty formatsLibravatar Junio C Hamano1-7/+11
"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats. Add --no-expand-tabs option to override the new default. The change alone breaks a test in t4201 that runs "git shortlog" on the output from "git log", and expects that the output from "git log" does not do such a tab expansion. Adjust the test to explicitly disable expand-tabs with --no-expand-tabs. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30pretty: expand tabs in indented logs to make things line up properlyLibravatar Linus Torvalds1-2/+69
A commit log message sometimes tries to line things up using tabs, assuming fixed-width font with the standard 8-place tab settings. Viewing such a commit however does not work well in "git log", as we indent the lines by prefixing 4 spaces in front of them. This should all line up: Column 1 Column 2 -------- -------- A B ABCD EFGH SPACES Instead of Tabs Even with multi-byte UTF8 characters: Column 1 Column 2 -------- -------- Ä B åäö 100 A Møøse once bit my sister.. Tab-expand the lines in "git log --expand-tabs" output before prefixing 4 spaces. This is based on the patch by Linus Torvalds, but at this step, we require an explicit command line option to enable the behaviour. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20Remove get_object_hash.Libravatar brian m. carlson1-4/+4
Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Convert struct object to object_idLibravatar brian m. carlson1-5/+5
struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Add several uses of get_object_hash.Libravatar brian m. carlson1-4/+4
Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-06-29convert "enum date_mode" into a structLibravatar Jeff King1-14/+15
In preparation for adding date modes that may carry extra information beyond the mode itself, this patch converts the date_mode enum into a struct. Most of the conversion is fairly straightforward; we pass the struct as a pointer and dereference the type field where necessary. Locations that declare a date_mode can use a "{}" constructor. However, the tricky case is where we use the enum labels as constants, like: show_date(t, tz, DATE_NORMAL); Ideally we could say: show_date(t, tz, &{ DATE_NORMAL }); but of course C does not allow that. Likewise, we cannot cast the constant to a struct, because we need to pass an actual address. Our options are basically: 1. Manually add a "struct date_mode d = { DATE_NORMAL }" definition to each caller, and pass "&d". This makes the callers uglier, because they sometimes do not even have their own scope (e.g., they are inside a switch statement). 2. Provide a pre-made global "date_normal" struct that can be passed by address. We'd also need "date_rfc2822", "date_iso8601", and so forth. But at least the ugliness is defined in one place. 3. Provide a wrapper that generates the correct struct on the fly. The big downside is that we end up pointing to a single global, which makes our wrapper non-reentrant. But show_date is already not reentrant, so it does not matter. This patch implements 3, along with a minor macro to keep the size of the callers sane. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-05Merge branch 'rs/simple-cleanups'Libravatar Junio C Hamano1-1/+1
Code cleanups. * rs/simple-cleanups: sha1_name: use strlcpy() to copy strings pretty: use starts_with() to check for a prefix for-each-ref: use skip_prefix() to avoid duplicate string comparison connect: use strcmp() for string comparison
2015-02-22pretty: use starts_with() to check for a prefixLibravatar René Scharfe1-1/+1
Simplify the code and avoid duplication by using starts_with() instead of strlen() and strncmp() to check if a line starts with "encoding ". Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-20Merge branch 'jn/parse-config-slot'Libravatar Junio C Hamano1-3/+2
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-3/+2
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-07use skip_prefix() to avoid more magic numbersLibravatar René Scharfe1-30/+26
Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off and use skip_prefix() in more places for determining the lengths of prefix strings to avoid using dependent constants and other indirect methods. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Merge branch 'hj/pretty-naked-decoration'Libravatar Junio C Hamano1-0/+4
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-19Merge branch 'rs/export-strbuf-addchars'Libravatar Junio C Hamano1-7/+3
Code clean-up. * rs/export-strbuf-addchars: strbuf: use strbuf_addchars() for adding a char multiple times strbuf: export strbuf_addchars()
2014-09-19Merge branch 'jk/commit-author-parsing'Libravatar Junio C Hamano1-27/+6
Code clean-up. * jk/commit-author-parsing: determine_author_info(): copy getenv output determine_author_info(): reuse parsing functions date: use strbufs in date-formatting functions record_author_date(): use find_commit_header() record_author_date(): fix memory leak on malformed commit commit: provide a function to find a header in a buffer
2014-09-19Merge branch 'bb/date-iso-strict'Libravatar Junio C Hamano1-1/+4
"log --date=iso" uses a slight variant of ISO 8601 format that is made more human readable. A new "--date=iso-strict" option gives datetime output that is more strictly conformant. * bb/date-iso-strict: pretty: provide a strict ISO 8601 date format
2014-09-18pretty: add %D format specifierLibravatar Harry Jeffery1-0/+4
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-08strbuf: use strbuf_addchars() for adding a char multiple timesLibravatar René Scharfe1-7/+3
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-02Merge branch 'ta/pretty-parse-config'Libravatar Junio C Hamano1-1/+3
* ta/pretty-parse-config: pretty.c: make git_pretty_formats_config return -1 on git_config_string failure
2014-08-29pretty: provide a strict ISO 8601 date formatLibravatar Beat Bolli1-1/+4
Git's "ISO" date format does not really conform to the ISO 8601 standard due to small differences, and it cannot be parsed by ISO 8601-only parsers, e.g. those of XML toolchains. The output from "--date=iso" deviates from ISO 8601 in these ways: - a space instead of the `T` date/time delimiter - a space between time and time zone - no colon between hours and minutes of the time zone Add a strict ISO 8601 date format for displaying committer and author dates. Use the '%aI' and '%cI' format specifiers and add '--date=iso-strict' or '--date=iso8601-strict' date format names. See http://thread.gmane.org/gmane.comp.version-control.git/255879 and http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585 for discussion. Signed-off-by: Beat Bolli <bbolli@ewanet.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-27commit: provide a function to find a header in a bufferLibravatar Jeff King1-27/+6
Usually when we parse a commit, we read it line by line and handle each individual line (e.g., parse_commit and parse_commit_header). Sometimes, however, we only care about extracting a single header. Code in this situation is stuck doing an ad-hoc parse of the commit buffer. Let's provide a reusable function to locate a header within the commit. The code is modeled after pretty.c's get_header, which is used to extract the encoding. Since some callers may not have the "struct commit" to go along with the buffer, we drop that parameter. The only thing lost is a warning for truncated commits, but that's OK. This shouldn't happen in practice, and even if it does, there's no particular reason that this function needs to complain about it. It either finds the header it was asked for, or it doesn't (and in the latter case, the caller will typically complain). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-04pretty.c: make git_pretty_formats_config return -1 on git_config_string failureLibravatar Tanay Abhra1-1/+3
`git_pretty_formats_config()` continues without checking git_config_string's return value which can lead to a SEGFAULT. Instead return -1 when git_config_string fails signalling `git_config()` to die printing the location of the erroneous variable. Signed-off-by: Tanay Abhra <tanayabh@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-30pretty: make empty userformats truly emptyLibravatar Jeff King1-0/+5
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-30pretty: treat "--format=" as an empty userformatLibravatar Jeff King1-2/+2
Until now, we treated "--pretty=" or "--format=" as "give me the default format". This was not planned nor documented, but only what happened to work due to our parsing of "--pretty" (which should give the default format). Let's instead let these be an actual empty userformat. Otherwise one must write out the annoyingly long "--pretty=tformat:" to get the same behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-22Merge branch 'rs/code-cleaning'Libravatar Junio C Hamano1-6/+1
* rs/code-cleaning: remote-testsvn: use internal argv_array of struct child_process in cmd_import() bundle: use internal argv_array of struct child_process in create_bundle() fast-import: use hashcmp() for SHA1 hash comparison transport: simplify fetch_objs_via_rsync() using argv_array run-command: use internal argv_array of struct child_process in run_hook_ve() use commit_list_count() to count the members of commit_lists strbuf: use strbuf_addstr() for adding C strings
2014-07-17use commit_list_count() to count the members of commit_listsLibravatar René Scharfe1-6/+1
Call commit_list_count() instead of open-coding it repeatedly. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16Merge branch 'rs/code-cleaning'Libravatar Junio C Hamano1-1/+1
* rs/code-cleaning: fsck: simplify fsck_commit_buffer() by using commit_list_count() commit: use commit_list_append() instead of duplicating its code merge: simplify merge_trivial() by using commit_list_append() use strbuf_addch for adding single characters use strbuf_addbuf for adding strbufs
2014-07-16Merge branch 'maint-1.8.5' into maint-1.9Libravatar Junio C Hamano1-1/+1
* maint-1.8.5: annotate: use argv_array t7300: repair filesystem permissions with test_when_finished enums: remove trailing ',' after last item in enum
2014-07-10use strbuf_addbuf for adding strbufsLibravatar René Scharfe1-1/+1
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-10Merge branch 'mg/verify-commit'Libravatar Junio C Hamano1-2/+0
Add 'verify-commit' to be used in a way similar to 'verify-tag' is used. Further work on verifying the mergetags might be needed. * mg/verify-commit: t7510: test verify-commit t7510: exit for loop with test result verify-commit: scriptable commit signature verification gpg-interface: provide access to the payload gpg-interface: provide clear helper for struct signature_check
2014-07-09Merge branch 'jk/pretty-G-format-fixes'Libravatar Junio C Hamano1-0/+2
* jk/pretty-G-format-fixes: move "%G" format test from t7510 to t6006 pretty: avoid reading past end-of-string with "%G" t7510: check %G* pretty-format output t7510: test a commit signed by an unknown key t7510: use consistent &&-chains in loop t7510: stop referring to master in later tests
2014-07-09Merge branch 'jk/skip-prefix'Libravatar Junio C Hamano1-2/+1
* jk/skip-prefix: http-push: refactor parsing of remote object names imap-send: use skip_prefix instead of using magic numbers use skip_prefix to avoid repeated calculations git: avoid magic number with skip_prefix fetch-pack: refactor parsing in get_ack fast-import: refactor parsing of spaces stat_opt: check extra strlen call daemon: use skip_prefix to avoid magic numbers fast-import: use skip_prefix for parsing input use skip_prefix to avoid repeating strings use skip_prefix to avoid magic numbers transport-helper: avoid reading past end-of-string fast-import: fix read of uninitialized argv memory apply: use skip_prefix instead of raw addition refactor skip_prefix to return a boolean avoid using skip_prefix as a boolean daemon: mark some strings as const parse_diff_color_slot: drop ofs parameter
2014-07-02Merge branch 'jk/commit-buffer-length'Libravatar Junio C Hamano1-34/+16
Move "commit->buffer" out of the in-core commit object and keep track of their lengths. Use this to optimize the code paths to validate GPG signatures in commit objects. * jk/commit-buffer-length: reuse cached commit buffer when parsing signatures commit: record buffer length in cache commit: convert commit->buffer to a slab commit-slab: provide a static initializer use get_commit_buffer everywhere convert logmsg_reencode to get_commit_buffer use get_commit_buffer to avoid duplicate code use get_cached_commit_buffer where appropriate provide helpers to access the commit buffer provide a helper to set the commit buffer provide a helper to free commit buffer sequencer: use logmsg_reencode in get_message logmsg_reencode: return const buffer do not create "struct commit" with xcalloc commit: push commit_index update into alloc_commit_node alloc: include any-object allocations in alloc_report replace dangerous uses of strbuf_attach commit_tree: take a pointer/len pair rather than a const strbuf
2014-07-02Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: t7300: repair filesystem permissions with test_when_finished enums: remove trailing ',' after last item in enum
2014-07-02Merge branch 'maint-1.8.5' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.8.5: t7300: repair filesystem permissions with test_when_finished enums: remove trailing ',' after last item in enum
2014-07-02enums: remove trailing ',' after last item in enumLibravatar Ronnie Sahlberg1-1/+1
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-23gpg-interface: provide clear helper for struct signature_checkLibravatar Michael J Gruber1-2/+1
The struct has been growing members whose malloced memory needs to be freed. Do this with one helper function so that no malloced memory shall be left unfreed. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-20use skip_prefix to avoid repeating stringsLibravatar Jeff King1-2/+1
It's a common idiom to match a prefix and then skip past it with strlen, like: if (starts_with(foo, "bar")) foo += strlen("bar"); This avoids magic numbers, but means we have to repeat the string (and there is no compiler check that we didn't make a typo in one of the strings). We can use skip_prefix to handle this case without repeating ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-17pretty: avoid reading past end-of-string with "%G"Libravatar Jeff King1-0/+2
If the user asks for --format=%G with nothing else, we correctly realize that "%G" is not a valid placeholder (it should be "%G?", "%GK", etc). But we still tell the strbuf_expand code that we consumed 2 characters, causing it to jump over the trailing NUL and output garbage. This also fixes the case where "%GX" would be consumed (and produce no output). In other cases, we pass unrecognized placeholders through to the final string. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-16Merge branch 'as/pretty-truncate'Libravatar Junio C Hamano1-1/+6
* as/pretty-truncate: pretty.c: format string with truncate respects logOutputEncoding t4205, t6006: add tests that fail with i18n.logOutputEncoding set t4205 (log-pretty-format): use `tformat` rather than `format` t4041, t4205, t6006, t7102: don't hardcode tested encoding value t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
2014-06-13commit: record buffer length in cacheLibravatar Jeff King1-2/+2
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-13convert logmsg_reencode to get_commit_bufferLibravatar Jeff King1-29/+11
Like the callsites in the previous commit, logmsg_reencode already falls back to read_sha1_file when necessary. However, I split its conversion out into its own commit because it's a bit more complex. We return either: 1. The original commit->buffer 2. A newly allocated buffer from read_sha1_file 3. A reencoded buffer (based on either 1 or 2 above). while trying to do as few extra reads/allocations as possible. Callers currently free the result with logmsg_free, but we can simplify this by pointing them straight to unuse_commit_buffer. This is a slight layering violation, in that we may be passing a buffer from (3). However, since the end result is to free() anything except (1), which is unlikely to change, and because this makes the interface much simpler, it's a reasonable bending of the rules. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12logmsg_reencode: return const bufferLibravatar Jeff King1-7/+7
The return value from logmsg_reencode may be either a newly allocated buffer or a pointer to the existing commit->buffer. We would not want the caller to accidentally free() or modify the latter, so let's mark it as const. We can cast away the constness in logmsg_free, but only once we have determined that it is a free-able buffer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21pretty.c: format string with truncate respects logOutputEncodingLibravatar Alexey Shumkin1-1/+6
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given length with an appropriate padding. This works for non-ASCII texts when i18n.logOutputEncoding is UTF-8 only (independently of a printed commit message encoding) but does not work when i18n.logOutputEncoding is NOT UTF-8. In 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19) 'format_commit_item' function assumes commit message to be in UTF-8. And that was so until ecaee80 (pretty: --format output should honor logOutputEncoding, 2013-06-26) where conversion to logOutputEncoding was added before calling 'format_commit_message'. Correct this by converting a commit message to UTF-8 first (as it assumed in 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19)). Only after that convert a commit message to an actual logOutputEncoding. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02pretty: make show_ident_date publicLibravatar Jeff King1-2/+2
We use this function internally to format "Date" lines in commit logs, but other parts of the code will want it, too. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>