summaryrefslogtreecommitdiff
path: root/t/t4205-log-pretty-formats.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-12-09pretty format %(trailers): add a "key_value_separator"Libravatar Ævar Arnfjörð Bjarmason1-0/+33
Add a "key_value_separator" option to the "%(trailers)" pretty format, to go along with the existing "separator" argument. In combination these two options make it trivial to produce machine-readable (e.g. \0 and \0\0-delimited) format output. As elaborated on in a previous commit which added "keyonly" it was needlessly tedious to extract structured data from "%(trailers)" before the addition of this "key_value_separator" option. As seen by the test being added here extracting this data now becomes trivial. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-09pretty format %(trailers): add a "keyonly"Libravatar Ævar Arnfjörð Bjarmason1-1/+30
Add support for a "keyonly". This allows for easier parsing out of the key and value. Before if you didn't want to make assumptions about how the key was formatted. You'd need to parse it out as e.g.: --pretty=format:'%H%x00%(trailers:separator=%x00%x00)' \ '%x00%(trailers:separator=%x00%x00,valueonly)' And then proceed to deduce keys by looking at those two and subtracting the value plus the hardcoded ": " separator from the non-valueonly %(trailers) line. Now it's possible to simply do: --pretty=format:'%H%x00%(trailers:separator=%x00%x00,keyonly)' \ '%x00%(trailers:separator=%x00%x00,valueonly)' Which at least reduces it to a state machine where you get N keys and correlate them with N values. Even better would be to have a way to change the ": " delimiter to something easily machine-readable (a key might contain ": " too). A follow-up change will add support for that. I don't really have a use-case for just "keyonly" myself. I suppose it would be useful in some cases as "key=*" matches case-insensitively, so a plain "keyonly" will give you the variants of the keys you matched. I'm mainly adding it to fix the inconsistency with "valueonly". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-09pretty-format %(trailers): fix broken standalone "valueonly"Libravatar Ævar Arnfjörð Bjarmason1-0/+28
Fix %(trailers:valueonly) being a noop due to on overly eager optimization in format_trailer_info() which skips custom formatting if no custom options are given. When "valueonly" was added in d9b936db522 (pretty: add support for "valueonly" option in %(trailers), 2019-01-28) we forgot to add it to the list of options that optimization checks for. See e.g. the addition of "key" in 250bea0c165 (pretty: allow showing specific trailers, 2019-01-28) for a similar change where this wasn't missed. Thus the "valueonly" option in "%(trailers:valueonly)" was a noop and the output was equivalent to that of a plain "%(trailers)". This wasn't caught because the tests for it always combined it with other options. Fix the bug by adding !opts->value_only to the list. I initially attempted to make this more future-proof by setting a flag if we got to ":" in "%(trailers:" in format_commit_one() in pretty.c. However, "%(trailers:" is also parsed in trailers_atom_parser() in ref-filter.c. There is an outstanding patch[1] unify those two, and such a fix, or other future-proofing, such as changing "process_trailer_options" flags into a bitfield, would conflict with that effort. Let's instead do the bare minimum here as this aspect of trailers is being actively worked on by another series. Let's also test for a plain "valueonly" without any other options, as well as "separator". All the other existing options on the pretty.c path had tests where they were the only option provided. I'm also keeping a sanity test for "%(trailers:)" being the same as "%(trailers)". There's no reason to suspect it wouldn't be in the current implementation, but let's keep it in the interest of black box testing. 1. https://lore.kernel.org/git/pull.726.git.1599335291.gitgitgadget@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-07pretty format %(trailers) test: split a long lineLibravatar Ævar Arnfjörð Bjarmason1-1/+6
Split a very long line in a test introduced in 0b691d86851 (pretty: add support for separator option in %(trailers), 2019-01-28). This makes it easier to read, especially as follow-up commits will copy this test as a template. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-10Merge branch 'dl/pretty-reference'Libravatar Junio C Hamano1-0/+79
"git log" family learned "--pretty=reference" that gives the name of a commit in the format that is often used to refer to it in log messages. * dl/pretty-reference: SubmittingPatches: use `--pretty=reference` pretty: implement 'reference' format pretty: add struct cmt_fmt_map::default_date_mode_type pretty: provide short date format t4205: cover `git log --reflog -z` blindspot pretty.c: inline initalize format_context revision: make get_revision_mark() return const pointer completion: complete `tformat:` pretty format SubmittingPatches: remove dq from commit reference pretty-formats.txt: use generic terms for hash SubmittingPatches: use generic terms for hash
2019-11-20pretty: implement 'reference' formatLibravatar Denton Liu1-0/+43
The standard format for referencing other commits within some projects (such as git.git) is the reference format. This is described in Documentation/SubmittingPatches as If you want to reference a previous commit in the history of a stable branch, use the format "abbreviated hash (subject, date)", like this: .... Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) noticed that ... .... Since this format is so commonly used, standardize it as a pretty format. The tests that are implemented essentially show that the format-string does not change in response to various log options. This is useful because, for future developers, it shows that we've considered the limitations of the "canned format-string" approach and we are fine with them. Based-on-a-patch-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-20pretty: provide short date formatLibravatar René Scharfe1-0/+6
Add the placeholders %as and %cs to format author date and committer date, respectively, without the time part, like --date=short does, i.e. like YYYY-MM-DD. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-20t4205: cover `git log --reflog -z` blindspotLibravatar Denton Liu1-0/+30
The test suite does not include any tests where `--reflog` and `-z` are used together in `git log`. Cover this blindspot. Note that the `--pretty=oneline` case is written separately because it follows a slightly different codepath. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in names of testsLibravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Merge branch 'aw/pretty-trailers'Libravatar Junio C Hamano1-0/+117
The %(trailers) formatter in "git log --format=..." now allows to optionally pick trailers selectively by keyword, show only values, etc. * aw/pretty-trailers: pretty: add support for separator option in %(trailers) strbuf: separate callback for strbuf_expand:ing literals pretty: add support for "valueonly" option in %(trailers) pretty: allow showing specific trailers pretty: single return path in %(trailers) handling pretty: allow %(trailers) options with explicit value doc: group pretty-format.txt placeholders descriptions
2019-01-29pretty: add support for separator option in %(trailers)Libravatar Anders Waldenborg1-0/+36
By default trailer lines are terminated by linebreaks ('\n'). By specifying the new 'separator' option they will instead be separated by user provided string and have separator semantics rather than terminator semantics. The separator string can contain the literal formatting codes %n and %xNN allowing it to be things that are otherwise hard to type such as %x00, or comma and end-parenthesis which would break parsing. E.g: $ git log --pretty='%(trailers:key=Reviewed-by,valueonly,separator=%x00)' Signed-off-by: Anders Waldenborg <anders@0x63.nu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29pretty: add support for "valueonly" option in %(trailers)Libravatar Anders Waldenborg1-0/+6
With the new "key=" option to %(trailers) it often makes little sense to show the key, as it by definition already is knows which trailer is printed there. This new "valueonly" option makes it omit the key when printing trailers. E.g.: $ git show -s --pretty='%s%n%(trailers:key=Signed-off-by,valueonly)' aaaa88182 will show: > upload-pack: fix broken if/else chain in config callback > Jeff King <peff@peff.net> > Junio C Hamano <gitster@pobox.com> Signed-off-by: Anders Waldenborg <anders@0x63.nu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29pretty: allow showing specific trailersLibravatar Anders Waldenborg1-0/+57
Adds a new "key=X" option to "%(trailers)" which will cause it to only print trailer lines which match any of the specified keys. Signed-off-by: Anders Waldenborg <anders@0x63.nu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29pretty: allow %(trailers) options with explicit valueLibravatar Anders Waldenborg1-0/+18
In addition to old %(trailers:only) it is now allowed to write %(trailers:only=yes) By itself this only gives (the not quite so useful) possibility to have users change their mind in the middle of a formatting string (%(trailers:only=true,only=false)). However, it gives users the opportunity to override defaults from future options. Signed-off-by: Anders Waldenborg <anders@0x63.nu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-11log: add %S option (like --source) to log --formatLibravatar Issac Trotts1-0/+50
Make it possible to write for example git log --format="%H,%S" where the %S at the end is a new placeholder that prints out the ref (tag/branch) for each commit. Using %d might seem like an alternative but it only shows the ref for the last commit in the branch. Signed-off-by: Issac Trotts <issactrotts@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23pretty, ref-filter: format %(trailers) with no_divider optionLibravatar Jeff King1-0/+23
In both of these cases we know that we are feeding the trailer-parsing code a pure commit message. We should tell it so, which avoids false positives for a commit message that contains a "---" line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21t4205: sort log output in a hash-independent wayLibravatar brian m. carlson1-4/+4
This test enumerates log entries and then sorts them. For SHA-1, this produces results that happen to sort in the order specified in the test, but for other hash algorithms they sort differently. Ensure we sort the log entries in a hash-independent way by sorting on the ref name instead of the object ID. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02t4205: unfold across multiple linesLibravatar Taylor Blau1-1/+1
Tests in t4205 test the following: git log --format='%(trailers:unfold)' ... By ensuring the multi-line trailers are unfolded back onto the same line. t4205 only includes tests for 2-line trailers, but `unfold()` will fail for folded trailers on 3 or more lines. In preparation for adding subsequent tests in t6300 that test similar behavior in `git-for-each-ref(1)`, let's harden t4205 (and make it consistent with the changes in t6300) by ensuring that 3 or more line folded trailers are unfolded correctly. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02pretty.c: delimit "%(trailers)" arguments with ","Libravatar Taylor Blau1-2/+2
In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or "%(trailers:only,unfold)". This change disambiguates between "top-level" arguments, and arguments given to the trailers atom itself. It is consistent with the behavior of "%(upstream)" and "%(push)" atoms. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15pretty: support normalization options for %(trailers)Libravatar Jeff King1-0/+33
The interpret-trailers command recently learned some options to make its output easier to parse (for a caller whose only interested in picking out the trailer values). But it's not very efficient for asking for the trailers of many commits in a single invocation. We already have "%(trailers)" to do that, but it doesn't know about unfolding or omitting non-trailers. Let's plumb those options through, so you can have the best of both. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15t4205: refactor %(trailers) testsLibravatar Jeff King1-8/+12
We currently have one test for %(trailers). In preparation for more, let's refactor a few bits: - move the commit creation to its own setup step so it can be reused by multiple tests - add a trailer with whitespace continuation (to confirm that it is left untouched) - fix the sample text which claims the placeholder is %bT. This was switched long ago to %(trailers) - replace one "cat" with an "echo" when generating the expected output. This saves a process (and sets a better pattern for future tests to follow). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-11tests: fix tests broken under GETTEXT_POISON=YesPleaseLibravatar Ævar Arnfjörð Bjarmason1-2/+2
The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on the list ("[BUG] test suite broken with GETTEXT_POISON=YesPlease", [1]) asking whether this mode was useful at all anymore. At least one person occasionally uses it, and Lars Schneider offered to change one of the the Travis builds to run in this mode, so fix up the failing ones. My test setup runs most of the tests, with the notable exception of skipping all the p4 tests, so it's possible that there's still some lurking regressions I haven't fixed. 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-11pretty: add %(trailers) format for displaying trailers of a commit messageLibravatar Jacob Keller1-0/+26
Recent patches have expanded on the trailers.c code and we have the builtin commant git-interpret-trailers which can be used to add or modify trailer lines. However, there is no easy way to simply display the trailers of a commit message. Add support for %(trailers) format modifier which will use the trailer_info_get() calls to read trailers in an identical way as git interpret-trailers does. Use a long format option instead of a short name so that future work can more easily unify ref-filter and pretty formats. Add documentation and tests for the same. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27t4205: indent here documentsLibravatar Jeff King1-196/+196
Our usual style in the test scripts is to indent here documents with tabs, and use "<<-" to strip the tabs. The result is easier to read. This old test script did not do so in its inception, and further tests added onto it followed the local style. Let's bring it in line with our usual style. Some of the tests actually care quite a bit about whitespace, but none of them do so at the beginning of the line (because they use things like qz_to_tab_space to avoid depending on the literal whitespace), so we can do a fairly mechanical conversion. Most of the here-docs also use interpolation, so they have been left as "<<-EOF". In a few cases, though, where interpolation was not in use, I've converted them to "<<-\EOF" to match our usual "don't interpolate unless you need to" style. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27t4205: drop top-level &&-chainingLibravatar Jeff King1-2/+4
The test currently does something like: do_one() && do_two() && test_expect_success ... We generally avoid performing actions at the top-level of the script (outside of a test_expect block) for two reasons: 1. The test harness is not checking and reporting if they fail. 2. Their output is not handled correctly (not hidden by default, nor shown with "-v"). Using &&-chains seems like it should help with (1), but it doesn't. If either of the commands fails, we simply skip running the follow-on test entirely, and the test harness has no idea. We can fix this by pushing that setup into its own block. It _could_ go into the following test block, but since the result in this case is used by multiple tests, it's more clear to mark it explicitly as a distinct setup step. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty.c: support <direction>|(<negative number>) formsLibravatar Nguyễn Thái Ngọc Duy1-0/+33
%>|(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/+24
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>
2014-09-29Merge branch 'hj/pretty-naked-decoration'Libravatar Junio C Hamano1-0/+11
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 'bb/date-iso-strict'Libravatar Junio C Hamano1-0/+8
"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/+11
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-09Merge branch 'nd/strbuf-utf8-replace'Libravatar Junio C Hamano1-0/+7
* nd/strbuf-utf8-replace: utf8.c: fix strbuf_utf8_replace() consuming data beyond input string
2014-08-29pretty: provide a strict ISO 8601 date formatLibravatar Beat Bolli1-0/+8
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-11utf8.c: fix strbuf_utf8_replace() consuming data beyond input stringLibravatar Nguyễn Thái Ngọc Duy1-0/+7
The main loop in strbuf_utf8_replace() could summed up as: while ('src' is still valid) { 1) advance 'src' to copy ANSI escape sequences 2) advance 'src' to copy/replace visible characters } The problem is after #1, 'src' may have reached the end of the string (so 'src' points to NUL) and #2 will continue to copy that NUL as if it's a normal character. Because the output is stored in a strbuf, this NUL accounted in the 'len' field as well. Check after #1 and break the loop if necessary. The test does not look obvious, but the combination of %>>() should make a call trace like this show_log() pretty_print_commit() format_commit_message() strbuf_expand() format_commit_item() format_and_pad_commit() strbuf_utf8_replace() where %C(auto)%d would insert a color reset escape sequence in the end of the string given to strbuf_utf8_replace() and show_log() uses fwrite() to send everything to stdout (including the incorrect NUL inserted by strbuf_utf8_replace) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-15tests: do not pass iso8859-1 encoded parameterLibravatar Pat Thoyts1-1/+1
git commit -m with some iso8859-1 encoded stuff is doomed to fail in MinGW, because Windows don't let you pass encoded bytes to a process (CreateProcessW always takes a UTF-16LE encoded string). It is safe to pass the iso8859-1 message using a file or a pipe. Thanks-to: Karsten Blees <blees@dcon.de> Author: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21pretty.c: format string with truncate respects logOutputEncodingLibravatar Alexey Shumkin1-4/+4
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-21t4205, t6006: add tests that fail with i18n.logOutputEncoding setLibravatar Alexey Shumkin1-0/+140
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. There were no breakages as far as were no tests for the case when both a commit message and logOutputEncoding are not UTF-8. Add failing tests for that which will be fixed in the next patch. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4205 (log-pretty-format): use `tformat` rather than `format`Libravatar Alexey Shumkin1-39/+13
Use `tformat` to avoid using of `echo` to complete end of line. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4041, t4205, t6006, t7102: don't hardcode tested encoding valueLibravatar Alexey Shumkin1-4/+7
The tested encoding is always available in a variable. Use it instead of hardcoding. Also, to be in line with other tests use ISO8859-1 (uppercase) rather then iso8859-1. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-3/+11
The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. That was introduced in a742f2a (t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was not followed in 5e1361c (log: properly handle decorations with chained tags, 2013-12-17) Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-20log: properly handle decorations with chained tagsLibravatar brian m. carlson1-0/+15
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-07-05t4205 (log-pretty-formats): avoid using `sed`Libravatar Alexey Shumkin1-16/+10
For testing truncated log messages 'commit_msg' function uses `sed` to cut a message. On various platforms `sed` behaves differently and results of its work depend on locales installed. So, avoid using `sed`. Use predefined expected outputs instead of calculated ones. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4205, t6006, t7102: make functions better readableLibravatar Alexey Shumkin1-1/+2
Function 'test_format' has become harder to read after its change in de6029a2 (pretty: Add failing tests: --format output should honor logOutputEncoding, 2013-06-26). Simplify it by moving its "should we expect it to fail?" parameter to the end. Note, current code does not use this last parameter as far as there are no tests expected to fail. We can keep that for future use. Also, reformat comments. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Improved-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4205 (log-pretty-formats): revert back single quotesLibravatar Alexey Shumkin1-53/+53
In previuos commit de6029a (pretty: Add failing tests: --format output should honor logOutputEncoding, 2013-06-26) single quotes were replaced with double quotes to make "$(commit_msg)" expression in heredoc to work. The same effect can be achieved by using "EOF" as a heredoc delimiter instead of "\EOF". Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Suggested-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1Libravatar Alexey Shumkin1-4/+4
Both "iso8859-1" and "iso-8859-1" are understood as latin-1 by modern platforms, but the latter is not understood by older platforms;update tests to use the former. This is in line with 3994e8a9 (t4201: use ISO8859-1 rather than ISO-8859-1, 2009-12-03), which did the same. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-01t4205: replace .\+ with ..* in sed commandsLibravatar Brian Gernhardt1-2/+2
OS X's sed only accepts basic regular expressions, which does not allow the + quantifier. However '..*' (anything, followed by zero or more anything) is the same as '.\+' (one or more anything) and valid in any regular expression language. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26pretty: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-17/+17
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-26pretty: Add failing tests: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-56/+93
One can set an alias $ git config 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 adds failing tests for the next patch that fixes them. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-22/+26
The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty: support %>> that steal trailing spacesLibravatar Nguyễn Thái Ngọc Duy1-0/+14
This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not use up all 100 columns and %an needs more than 20 columns. By replacing %>(20) with %>>(20), %an can steal spaces from %s. %>> understands escape sequences, so %Cred does not stop it from stealing spaces in %<(100). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty: support truncating in %>, %< and %><Libravatar Nguyễn Thái Ngọc Duy1-0/+39
%>(N,trunc) truncates the right part after N columns and replace the last two letters with "..". ltrunc does the same on the left. mtrunc cuts the middle out. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>