summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-08-01use strbuf_addstr() for adding constant strings to a strbufLibravatar René Scharfe1-3/+3
Replace uses of strbuf_addf() for adding strings with more lightweight strbuf_addstr() calls. In http-push.c it becomes easier to see what's going on without having to verfiy that the definition of PROPFIND_ALL_REQUEST doesn't contain any format specifiers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'ak/lazy-prereq-mktemp' into maintLibravatar Junio C Hamano1-1/+6
A test that unconditionally used "mktemp" learned that the command is not necessarily available everywhere. * ak/lazy-prereq-mktemp: t7610: test for mktemp before test execution
2016-07-28Merge branch 'nd/icase' into maintLibravatar Junio C Hamano4-3/+148
"git grep -i" has been taught to fold case in non-ascii locales correctly. * nd/icase: grep.c: reuse "icase" variable diffcore-pickaxe: support case insensitive match on non-ascii diffcore-pickaxe: Add regcomp_or_die() grep/pcre: support utf-8 gettext: add is_utf8_locale() grep/pcre: prepare locale-dependent tables for icase matching grep: rewrite an if/else condition to avoid duplicate expression grep/icase: avoid kwsset when -F is specified grep/icase: avoid kwsset on literal non-ascii strings test-regex: expose full regcomp() to the command line test-regex: isolate the bug test code grep: break down an "if" stmt in preparation for next changes
2016-07-28Merge branch 'jk/test-match-signal' into maintLibravatar Junio C Hamano3-11/+26
The test framework learned a new helper test_match_signal to check an exit code from getting killed by an expected signal. * jk/test-match-signal: t/lib-git-daemon: use test_match_signal test_must_fail: use test_match_signal t0005: use test_match_signal as appropriate tests: factor portable signal check out of t0005
2016-07-28Merge branch 'js/t3404-grammo-fix' into maintLibravatar Junio C Hamano1-1/+1
Grammofix. * js/t3404-grammo-fix: t3404: fix a grammo (commands are ran -> commands are run)
2016-07-28Merge branch 'ps/rebase-i-auto-unstash-upon-abort' into maintLibravatar Junio C Hamano1-0/+31
"git rebase -i --autostash" did not restore the auto-stashed change when the operation was aborted. * ps/rebase-i-auto-unstash-upon-abort: rebase -i: restore autostash on abort
2016-07-28Merge branch 'nd/ita-cleanup' into maintLibravatar Junio C Hamano1-1/+59
Git does not know what the contents in the index should be for a path added with "git add -N" yet, so "git grep --cached" should not show hits (or show lack of hits, with -L) in such a path, but that logic does not apply to "git grep", i.e. searching in the working tree files. But we did so by mistake, which has been corrected. * nd/ita-cleanup: grep: fix grepping for "intent to add" files t7810-grep.sh: fix a whitespace inconsistency t7810-grep.sh: fix duplicated test name
2016-07-28Merge branch 'js/find-commit-subject-ignore-leading-blanks' into maintLibravatar Junio C Hamano1-0/+17
A helper function that takes the contents of a commit object and finds its subject line did not ignore leading blank lines, as is commonly done by other codepaths. Make it ignore leading blank lines to match. * js/find-commit-subject-ignore-leading-blanks: reset --hard: skip blank lines when reporting the commit subject sequencer: use skip_blank_lines() to find the commit subject commit -C: skip blank lines at the beginning of the message commit.c: make find_commit_subject() more robust pretty: make the skip_blank_lines() function public
2016-07-28Merge branch 'dg/subtree-rebase-test' into maintLibravatar Junio C Hamano1-0/+119
Add a test to specify the desired behaviour that currently is not available in "git rebase -Xsubtree=...". * dg/subtree-rebase-test: contrib/subtree: Add a test for subtree rebase that loses commits
2016-07-15Merge branch 'jk/tzoffset-fix' into maintLibravatar Junio C Hamano2-3/+12
Skip tests that are unrunnable on platforms without 64-bit long to avoid unnecessary test failures. * jk/tzoffset-fix: t0006: skip "far in the future" test when unsigned long is not long enough
2016-07-15t0006: skip "far in the future" test when unsigned long is not long enoughLibravatar Jeff King2-3/+12
Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". While we can fix this issue properly by replacing unsigned long with a larger type, we want to be a bit more conservative and just skip those tests on the maint track. Signed-off-by: Jeff King <peff@peff.net> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11Merge branch 'jc/t2300-setup' into maintLibravatar Junio C Hamano1-1/+9
Portability fix for Windows. * jc/t2300-setup: t2300: "git --exec-path" is not usable in $PATH on Windows as-is
2016-07-11Merge branch 'cb/t7810-test-label-fix' into maintLibravatar Junio C Hamano1-1/+1
Test clean-up. * cb/t7810-test-label-fix: t7810: fix duplicated test title
2016-07-11Merge branch 'sb/t5614-modernize' into maintLibravatar Junio C Hamano1-50/+20
Test clean-up. * sb/t5614-modernize: t5614: don't use subshells
2016-07-11Merge branch 'js/perf-on-apple' into maintLibravatar Junio C Hamano1-1/+5
t/perf needs /usr/bin/time with GNU extension; the invocation of it is updated to "gtime" on Darwin. * js/perf-on-apple: perf: accommodate for MacOSX
2016-07-11Merge branch 'ak/t7800-wo-readlink' into maintLibravatar Junio C Hamano1-1/+1
One among four invocations of readlink(1) in our test suite has been rewritten so that the test can run on systems without the command (others are in valgrind test framework and t9802). * ak/t7800-wo-readlink: t7800: readlink may not be available
2016-07-11Merge branch 'jk/tzoffset-fix' into maintLibravatar Junio C Hamano2-17/+69
The internal code used to show local timezone offset is not prepared to handle timestamps beyond year 2100, and gave a bogus offset value to the caller. Use a more benign looking +0000 instead and let "git log" going in such a case, instead of aborting. * jk/tzoffset-fix: local_tzoffset: detect errors from tm_to_time_t t0006: test various date formats t0006: rename test-date's "show" to "relative"
2016-07-11Merge branch 'sb/clone-shallow-passthru' into maintLibravatar Junio C Hamano1-2/+17
Fix an unintended regression in v2.9 that breaks "clone --depth" that recurses down to submodules by forcing the submodules to also be cloned shallowly, which many server instances that host upstream of the submodules are not prepared for. * sb/clone-shallow-passthru: clone: do not let --depth imply --shallow-submodules
2016-07-11Merge branch 'nd/graph-width-padded' into maintLibravatar Junio C Hamano1-0/+57
"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-07-06Merge branch 'et/add-chmod-x' into maintLibravatar Junio C Hamano1-0/+30
"git update-index --add --chmod=+x file" may be usable as an escape hatch, but not a friendly thing to force for people who do need to use it regularly. "git add --chmod=+x file" can be used instead. * et/add-chmod-x: add: add --chmod=+x / --chmod=-x options
2016-07-06Merge branch 'sg/reflog-past-root' into maintLibravatar Junio C Hamano2-1/+23
"git reflog" stopped upon seeing an entry that denotes a branch creation event (aka "unborn"), which made it appear as if the reflog was truncated. * sg/reflog-past-root: reflog: continue walking the reflog past root commits
2016-07-06t7610: test for mktemp before test executionLibravatar Armin Kunaschik1-1/+6
mktemp is not available on all platforms, so the test 'temporary filenames are used with mergetool.writeToTemp' fails there. This patch does not replace mktemp but just disables the test that otherwise would fail. mergetool checks itself before executing mktemp and reports an error. Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06t/lib-git-daemon: use test_match_signalLibravatar Jeff King1-2/+1
When git-daemon exits, we expect it to be with the SIGTERM we just sent it. If we see anything else, we'll complain. But our check against exit code "143" is not portable. For example: $ ksh93 t5570-git-daemon.sh [...] error: git daemon exited with status: 271 We can fix this by using test_match_signal. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06test_must_fail: use test_match_signalLibravatar Jeff King1-1/+1
In 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27), test_must_fail learned to recognize "141" as a sigpipe failure. However, testing for a signal is more complicated than that; we should use test_match_signal to implement more portable checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06t0005: use test_match_signal as appropriateLibravatar Jeff King1-2/+2
The first test already uses this more portable construct (that was where it was factored from initially), but the later tests do a raw comparison against 141 to look for SIGPIPE, which can fail on some shells and platforms. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06tests: factor portable signal check out of t0005Libravatar Jeff King2-6/+22
In POSIX shells, a program which exits due to a signal generally has an exit code of 128 plus the signal number. However, ksh uses 256 plus the signal number. We've accounted for that in t0005, but not in other tests. Let's pull out the logic so we can use it elsewhere. It would be nice for debugging if this additionally printed errors to stderr, like our other test_* helpers. But we're going to need to use it in other places besides the innards of a test_expect block. So let's leave it as generic as possible. Note that we also leave the magic "3" for Windows out of the generic helper. This is an artifact of the way we use raise() to kill ourselves in test-sigchain.c, and will not necessarily apply to all programs. So it's better to keep it out of the helper, to reduce the chance of confusing it with a real call to exit(3). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01grep: fix grepping for "intent to add" filesLibravatar Charles Bailey1-0/+58
This reverts commit 4d5520053 (grep: make it clear i-t-a entries are ignored, 2015-12-27) and adds an alternative fix to maintain the -L --cached behavior. 4d5520053 caused 'git grep' to no longer find matches in new files in the working tree where the corresponding index entry had the "intent to add" bit set, despite the fact that these files are tracked. The content in the index of a file for which the "intent to add" bit is set is considered indeterminate and not empty. For most grep queries we want these to behave the same, however for -L --cached (files without a match) we don't want to respond positively for "intent to add" files as their contents are indeterminate. This is in contrast to files with empty contents in the index (no lines implies no matches for any grep query expression) which should be reported in the output of a grep -L --cached invocation. Add tests to cover this case and a few related cases which previously lacked coverage. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01t7810-grep.sh: fix a whitespace inconsistencyLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01t7810-grep.sh: fix duplicated test nameLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01diffcore-pickaxe: support case insensitive match on non-asciiLibravatar Nguyễn Thái Ngọc Duy1-0/+7
Similar to the "grep -F -i" case, we can't use kws on icase search outside ascii range, so we quote the string and pass it to regcomp as a basic regexp and let regex engine deal with case sensitivity. The new test is put in t7812 instead of t4209-log-pickaxe because lib-gettext.sh might cause problems elsewhere, probably. Noticed-by: Plamen Totev <plamen.totev@abv.bg> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01grep/pcre: support utf-8Libravatar Nguyễn Thái Ngọc Duy1-0/+15
In the previous change in this function, we add locale support for single-byte encodings only. It looks like pcre only supports utf-* as multibyte encodings, the others are left in the cold (which is fine). We need to enable PCRE_UTF8 so pcre can find character boundary correctly. It's needed for case folding (when --ignore-case is used) or '*', '+' or similar syntax is used. The "has_non_ascii()" check is to be on the conservative side. If there's non-ascii in the pattern, the searched content could still be in utf-8, but we can treat it just like a byte stream and everything should work. If we force utf-8 based on locale only and pcre validates utf-8 and the file content is in non-utf8 encoding, things break. Noticed-by: Plamen Totev <plamen.totev@abv.bg> Helped-by: Plamen Totev <plamen.totev@abv.bg> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01grep/pcre: prepare locale-dependent tables for icase matchingLibravatar Nguyễn Thái Ngọc Duy1-0/+19
The default tables are usually built with C locale and only suitable for LANG=C or similar. This should make case insensitive search work correctly for all single-byte charsets. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01grep/icase: avoid kwsset when -F is specifiedLibravatar Nguyễn Thái Ngọc Duy1-0/+26
Similar to the previous commit, we can't use kws on icase search outside ascii range. But we can't simply pass the pattern to regcomp/pcre like the previous commit because it may contain regex special characters, so we need to quote the regex first. To avoid misquote traps that could lead to undefined behavior, we always stick to basic regex engine in this case. We don't need fancy features for grepping a literal string anyway. basic_regex_quote_buf() assumes that if the pattern is in a multibyte encoding, ascii chars must be unambiguously encoded as single bytes. This is true at least for UTF-8. For others, let's wait until people yell up. Chances are nobody uses multibyte, non utf-8 charsets anymore. Noticed-by: Plamen Totev <plamen.totev@abv.bg> Helped-by: René Scharfe <l.s.r@web.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-29t3404: fix a grammo (commands are ran -> commands are run)Libravatar Johannes Schindelin1-1/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-29rebase -i: restore autostash on abortLibravatar Patrick Steinhardt1-0/+31
When we abort an interactive rebase we do so by calling `die_abort`, which cleans up after us by removing the rebase state directory. If the user has requested to use the autostash feature, though, the state directory may also contain a reference to the autostash, which will now be deleted. Fix the issue by trying to re-apply the autostash in `die_abort`. This will also handle the case where the autostash does not apply cleanly anymore by recording it in a user-visible stash. Reported-by: Daniel Hahler <git@thequod.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28contrib/subtree: Add a test for subtree rebase that loses commitsLibravatar David A. Greene1-0/+119
This test merges an external tree in as a subtree, makes some commits on top of it and splits it back out. In the process the added commits are lost or the rebase aborts with an internal error. The tests are marked to expect failure so that we don't forget to fix it. Signed-off-by: David A. Greene <greened@obbligato.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27Merge branch 'rs/xdiff-hunk-with-func-line' into maintLibravatar Junio C Hamano7-77/+278
"git show -W" (extend hunks to cover the entire function, delimited by lines that match the "funcname" pattern) used to show the entire file when a change added an entire function at the end of the file, which has been fixed. * rs/xdiff-hunk-with-func-line: xdiff: fix merging of appended hunk with -W grep: -W: don't extend context to trailing empty lines t7810: add test for grep -W and trailing empty context lines xdiff: don't trim common tail with -W xdiff: -W: don't include common trailing empty lines in context xdiff: ignore empty lines before added functions with -W xdiff: handle appended chunks better with -W xdiff: factor out match_func_rec() t4051: rewrite, add more tests
2016-06-27Merge branch 'jk/rev-list-count-with-bitmap' into maintLibravatar Junio C Hamano1-0/+6
"git rev-list --count" whose walk-length is limited with "-n" option did not work well with the counting optimized to look at the bitmap index. * jk/rev-list-count-with-bitmap: rev-list: disable bitmaps when "-n" is used with listing objects rev-list: "adjust" results of "--count --use-bitmap-index -n"
2016-06-27Merge branch 'et/pretty-format-c-auto' into maintLibravatar Junio C Hamano1-7/+19
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-27grep/icase: avoid kwsset on literal non-ascii stringsLibravatar Nguyễn Thái Ngọc Duy1-0/+23
When we detect the pattern is just a literal string, we avoid heavy regex engine and use fast substring search implemented in kwsset.c. But kws uses git-ctype which is locale-independent so it does not know how to fold case properly outside ascii range. Let regcomp or pcre take care of this case instead. Slower, but accurate. Noticed-by: Plamen Totev <plamen.totev@abv.bg> Helped-by: René Scharfe <l.s.r@web.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27test-regex: isolate the bug test codeLibravatar Nguyễn Thái Ngọc Duy1-1/+1
This is in preparation to turn test-regex into some generic regex testing command. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-22t2300: "git --exec-path" is not usable in $PATH on Windows as-isLibravatar Johannes Schindelin1-1/+9
The "git" command prepends the exec-path to the PATH environment variable for processes it spawns. That is how ". git-sh-setup" in our scripted Porcelains can find the dot-sourced file in the exec-path location that is not usually on user's PATH. When t2300 runs, because it is not spawned by the "git" command, the scriptlet being tested did not run with a realistic setting of PATH environment. It lacked the exec-path on the PATH, and failed to find the dot-sourced file. A recent update to t2300 attempted to fix this, with "PATH=$(git --exec-path):$PATH", which has been the recommended way around v1.6.0 days (a script whose original was written before that release that survives to this day is likely to have such a line). However, the "git --exec-path" command outputs C:\path\to\exec\dir (not /c/path/to/exec/dir) on Windows; the recent update failed to consider the problem that comes from it. Even though Git itself, when doing the equivalent internally, does so in a platform native way (i.e. on Windows, C:\path\to\exec\dir is prepended to the existing value of %PATH% using ';' as a component separator), the result is further massaged by bash and gets turned into $PATH that uses /c/path/to/exec/dir with ':' separating the components, which is the form understood by bash, so scripted Porcelains find commands from PATH correctly. An end user script written in shell, however, cannot prepend "C:\path\to\exec\dir:" to the existing value of $PATH and expect bash to magically turn it into the form it understands. In other words, "PATH=$(git --exec-path):$PATH" does not work as an emulation of what "Git" internally does to the PATH on Windows. To correctly emulate how exec-path is prepended to the PATH environment internally on Windows, we'd need to convert C:\git-sdk-64\usr\src\git to at least /c\git-sdk-64\usr\src\git ourselves before prepending it to PATH. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-22commit.c: make find_commit_subject() more robustLibravatar Johannes Schindelin1-0/+17
Just like the pretty printing machinery, we should simply ignore blank lines at the beginning of the commit messages. This discrepancy was noticed when an early version of the rebase--helper produced commit objects with more than one empty line between the header and the commit message. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t7810: fix duplicated test titleLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t5614: don't use subshellsLibravatar Stefan Beller1-50/+20
Using a subshell for just one git command is both a waste in compute overhead (create a new process) as well as in line count. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t7800: readlink may not be availableLibravatar Armin Kunaschik1-1/+1
The readlink(1) command is not available on all platforms (notably not on AIX and HP-UX) and can be replaced in this test with the "workaround" ls -ld <name> | sed -e 's/.* -> //' This is no universal readlink replacement but works in the controlled test environment well enough. Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21perf: accommodate for MacOSXLibravatar Johannes Schindelin1-1/+5
As this developer has no access to MacOSX developer setups anymore, Travis becomes the best bet to run performance tests on that OS. However, on MacOSX /usr/bin/time is that good old BSD executable that no Linux user cares about, as demonstrated by the perf-lib.sh's use of GNU-ish extensions. And by the hard-coded path. Let's just work around this issue by using gtime on MacOSX, the Homebrew-provided GNU implementation onto which pretty much every MacOSX power user falls back anyway. To help other developers use Travis to run performance tests on MacOSX, the .travis.yml file now sports a commented-out line that installs GNU time via Homebrew. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20local_tzoffset: detect errors from tm_to_time_tLibravatar Jeff King1-0/+5
When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20t0006: test various date formatsLibravatar Jeff King1-0/+21
We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20t0006: rename test-date's "show" to "relative"Libravatar Jeff King1-13/+13
The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>