summaryrefslogtreecommitdiff
path: root/t/annotate-tests.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-02-05Merge branch 'pb/blame-funcname-range-userdiff'Libravatar Junio C Hamano1-4/+4
Test fix. * pb/blame-funcname-range-userdiff: annotate-tests: quote variable expansions containing path names
2021-01-30annotate-tests: quote variable expansions containing path namesLibravatar Johannes Sixt1-4/+4
The test case added by 9466e3809d ("blame: enable funcname blaming with userdiff driver", 2020-11-01) forgot to quote variable expansions. This causes failures when the current directory contains blanks. One variable that the test case introduces will not have IFS characters and could remain without quotes, but let's quote all expansions for consistency, not just the one that has the path name. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t8*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-4/+4
This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t8*.sh annotate*.sh) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-01blame: enable funcname blaming with userdiff driverLibravatar Philippe Blain1-0/+18
In blame.c::cmd_blame, we send the 'path' field of the 'sb' 'struct blame_scoreboard' as the 'path' argument to 'line-range.c::parse_range_arg', but 'sb.path' is not set yet; it's set to the local variable 'path' a few lines later at line 1137. This 'path' argument is only used in 'parse_range_arg' if we are blaming a funcname, i.e. `git blame -L :<funcname> <path>`, and in that case it is sent to 'parse_range_funcname', where it is used to determine if a userdiff driver should be used for said <path> to match the given funcname. Since 'path' is yet unset, the userdiff driver is never used, so we fall back to the default funcname regex, which is usually not appropriate for paths that are set to use a specific userdiff driver, and thus either we match some unrelated lines, or we die with fatal: -L parameter '<funcname>' starting at line 1: no match This has been the case ever since `git blame` learned to blame a funcname in 13b8f68c1f (log -L: :pattern:file syntax to find by funcname, 2013-03-28). Enable funcname blaming for paths using specific userdiff drivers by initializing 'sb.path' earlier in 'cmd_blame', when some of its other fields are initialized, so that it is set when passed to 'parse_range_arg'. Add a regression test in 'annotate-tests.sh', which is sourced in t8001-annotate.sh and t8002-blame.sh, leveraging an existing file used to test the userdiff patterns in t4018-diff-funcname. Also, use 'sb.path' instead of 'path' when constructing the error message at line 1114, for consistency. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08blame: default to HEAD in a bare repo when no start commit is givenLibravatar SZEDER Gábor1-0/+8
When 'git blame' is invoked without specifying the commit to start blaming from, it starts from the given file's state in the work tree. However, when invoked in a bare repository without a start commit, then there is no work tree state to start from, and it dies with the following error message: $ git rev-parse --is-bare-repository true $ git blame file.c fatal: this operation must be run in a work tree This is misleading, because it implies that 'git blame' doesn't work in bare repositories at all, but it does, in fact, work just fine when it is given a commit to start from. We could improve the error message, of course, but let's just default to HEAD in a bare repository instead, as most likely that is what the user wanted anyway (if they wanted to start from an other commit, then they would have specified that in the first place). 'git annotate' is just a thin wrapper around 'git blame', so in the same situation it printed the same misleading error message, and this patch fixes it, too. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-15blame: prevent error if range ends past end of fileLibravatar Isabella Stephens1-2/+2
If the -L option is used to specify a line range in git blame, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behavior - instead we display the blame for existing lines within the specified range. Tests are amended accordingly. This commit also fixes two corner cases. Blaming -L n,-(n+1) now blames the first n lines of a file rather than from n to the end of the file. Blaming -L ,-n will be treated as -L 1,-n and blame the first line of the file, rather than blaming the whole file. Signed-off-by: Isabella Stephens <istephens@atlassian.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-24blame: fix object casting regressionLibravatar Jeff King1-0/+7
Commit 1b0d400 refactored the prepare_final() function so that it could be reused in multiple places. Originally, the loop had two outputs: a commit to stuff into sb->final, and the name of the commit from the rev->pending array. After the refactor, that loop is put in its own function with a single return value: the object_array_entry from the rev->pending array. This contains both the name and the object, but with one important difference: the object is the _original_ object found by the revision parser, not the dereferenced commit. If one feeds a tag to "git blame", we end up casting the tag object to a "struct commit", which causes a segfault. Instead, let's return the commit (properly casted) directly from the function, and take the "name" as an optional out-parameter. This does the right thing, and actually simplifies the callers, who no longer need to cast or dereference the object_array_entry themselves. [test case by Max Kirillov <max@max630.net>] Signed-off-by: Jeff King <peff@peff.net>
2015-09-16blame: handle --first-parentLibravatar Jeff King1-0/+4
The revision.c options-parser will parse "--first-parent" for us, but the blame code does not actually respect it, as we simply iterate over the whole list returned by first_scapegoat(). We can fix this by returning a truncated parent list. Note that we could technically also do so by limiting the return value of num_scapegoats(), but that is less robust. We would rely on nobody ever looking at the "next" pointer from the returned list. Combining "--reverse" with "--first-parent" is more complicated, and will probably involve cooperation from revision.c. Since the desired semantics are not even clear, let's punt on this for now, but explicitly disallow it to avoid confusing users (this is not really a regression, since it did something nonsensical before). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21t800[12]: work around MSys limitationLibravatar Karsten Blees1-0/+12
MSys works very hard to convert Unix-style paths into DOS-style ones. *Very* hard. So hard, indeed, that git blame -L/hello/,/green/ is translated into something like git blame -LC:/msysgit/hello/,C:/msysgit/green/ As seen in msys_p2w in src\msys\msys\rt\src\winsup\cygwin\path.cc, line 3204ff: case '-': // // here we check for POSIX paths as attributes to a POSIX switch. // ... seemingly absolute POSIX paths in single-letter options get expanded by msys.dll unless they contain '=' or ';'. So a quick and very dirty fix is to use '-L/;*evil/'. (Using an equal sign works only when it is before a comma, so in the above example, /=*green/ would still be converted to a DOS-style path.) The -L mangling can be done by the script, just before the parameter is passed to the executable. This version does not modify the body of the tests and is active on MinGW only. Commit-message-by: Johannes Schindelin <johannes.schindelin@gmx.de> Author: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-27Remove the line length limit for graft filesLibravatar Johannes Schindelin1-0/+21
Support for grafts predates Git's strbuf, and hence it is understandable that there was a hard-coded line length limit of 1023 characters (which was chosen a bit awkwardly, given that it is *exactly* one byte short of aligning with the 41 bytes occupied by a commit name and the following space or new-line character). While regular commit histories hardly win comprehensibility in general if they merge more than twenty-two branches in one go, it is not Git's business to limit grafts in such a way. In this particular developer's case, the use case that requires substantially longer graft lines to be supported is the visualization of the commits' order implied by their changes: commits are considered to have an implicit relationship iff exchanging them in an interactive rebase would result in merge conflicts. Thusly implied branches tend to be very shallow in general, and the resulting thicket of implied branches is usually very wide; It is actually quite common that *most* of the commits in a topic branch have not even one implied parent, so that a final merge commit has about as many implied parents as there are commits in said branch. [jc: squashed in tests by Jonathan] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-31t: replace pulls with mergesLibravatar Felipe Contreras1-1/+1
This is what the code intended. No functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: reject -L line numbers less than 1Libravatar Eric Sunshine1-9/+9
Since inception, git-blame -L has been documented as accepting 1-based line numbers. When handed a line number less than 1, -L's behavior is undocumented and undefined; it's also nonsensical and should be diagnosed as an error. Do so. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06t8001/t8002: blame: add tests of -L line numbers less than 1Libravatar Eric Sunshine1-0/+12
git-blame -L is documented as accepting 1-based line numbers. When handed a line number less than 1, -L's behavior is undocumented and undefined; it's also nonsensical and should be rejected but is nevertheless accepted. Demonstrate this shortcoming. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L^:RE to search from start of fileLibravatar Eric Sunshine1-0/+17
The -L:RE option of blame/log searches from the end of the previous -L range, if any. Add new notation -L^:RE to override this behavior and search from start of file. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L:RE to search from end of previous -L rangeLibravatar Eric Sunshine1-0/+16
For consistency with -L/RE/, teach -L:RE to search relative to the end of the previous -L range, if any. The new behavior invalidates one test in t4211 which assumes that -L:RE begins searching at start of file. This test will be resurrected in a follow-up patch which teaches -L:RE how to override the default relative search behavior. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L^/RE/ to search from start of fileLibravatar Eric Sunshine1-0/+21
The -L/RE/ option of blame/log searches from the end of the previous -L range, if any. Add new notation -L^/RE/ to override this behavior and search from start of file. The new ^/RE/ syntax is valid only as the <start> argument of -L<start>,<end>. The <end> argument, as usual, is relative to <start>. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06blame: teach -L/RE/ to search from end of previous -L rangeLibravatar Eric Sunshine1-0/+20
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06t8001/t8002: blame: add tests of multiple -L optionsLibravatar Eric Sunshine1-0/+32
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05blame: reject empty ranges -L,+0 and -L,-0Libravatar Eric Sunshine1-2/+2
Empty ranges -L,+0 and -L,-0 are nonsensical in the context of blame yet they are accepted (in fact, both are interpreted as -L1,Y where Y is end-of-file). Report them as invalid. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t8001/t8002: blame: demonstrate acceptance of bogus -L,+0 and -L,-0Libravatar Eric Sunshine1-0/+8
Empty ranges -L,+0 and -L,-0 are nonsensical in the context of blame yet they are accepted. They should be errors. Demonstrate this shortcoming. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05blame: reject empty ranges -LX,+0 and -LX,-0Libravatar Eric Sunshine1-2/+2
Empty ranges -LX,+0 and -LX,-0 are nonsensical in the context of blame yet they are accepted (in fact, both are interpreted as -LX,+2). Report them as invalid. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t8001/t8002: blame: demonstrate acceptance of bogus -LX,+0 and -LX,-0Libravatar Eric Sunshine1-0/+8
Empty ranges -LX,+0 and -LX,-0 are nonsensical in the context of blame yet they are accepted. They should be errors. Demonstrate this shortcoming. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05blame: fix -L bounds checking bugLibravatar Eric Sunshine1-4/+4
Since inception, -LX,Y has correctly reported an out-of-range error when Y is beyond end of file, however, X was not checked, and an out-of-range X would cause a crash. 92f9e273 (blame: prevent a segv when -L given start > EOF; 2010-02-08) attempted to rectify this shortcoming but has its own off-by-one error which allows X to extend one line past end of file. For example, given a file with 5 lines: git blame -L5 foo # OK, blames line 5 git blame -L6 foo # accepted, no error, no output, huh? git blame -L7 foo # error "fatal: file foo has only 5 lines" Fix this bug. In order to avoid regressing "blame foo" when foo is an empty file, the fix is slightly more complicated than changing '<' to '<='. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t8001/t8002: blame: add empty file & partial-line testsLibravatar Eric Sunshine1-0/+72
Add boundary case tests, with and without -L, for empty file; file with one partial line; file with one full line. The empty file test without -L is of particular interest. Historically, this case has been supported (empty blame output) and this test protects against regression by a subsequent patch fixing an off-by-one bug which incorrectly accepts -LX where X is one past end-of-file. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t8001/t8002: blame: demonstrate -L bounds checking bugLibravatar Eric Sunshine1-0/+22
A bounds checking bug allows the X in -LX to extend one line past the end of file. For example, given a file with 5 lines, -L6 is accepted as valid. Demonstrate this problem. While here, also add tests to check that the remaining cases of X and Y in -LX,Y are handled correctly at and in the vicinity of end-of-file. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t8001/t8002: blame: decompose overly-large testLibravatar Eric Sunshine1-7/+25
Checking all bogus -L syntax forms in a single test makes it difficult to identify the offender when one case fails. Decompose this conglomerate test in order to check each bad syntax case separately. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t8001, t8002: fix "blame -L :literal" test on NetBSDLibravatar René Scharfe1-2/+2
Sub-test 42 of t8001 and t8002 ("blame -L :literal") fails on NetBSD with the following verbose output: git annotate -L:main hello.c Author F (expected 4, attributed 3) bad Author G (expected 1, attributed 1) good This is not caused by different behaviour of git blame or annotate on that platform, but by different test input, in turn caused by a sed command that forgets to add a newline on NetBSD. Here's the diff of the commit that adds "goodbye" to hello.c, for Linux: @@ -1,4 +1,5 @@ int main(int argc, const char *argv[]) { puts("hello"); + puts("goodbye"); } We see that it adds an extra TAB, but that's not a problem. Here's the same on NetBSD: @@ -1,4 +1,4 @@ int main(int argc, const char *argv[]) { puts("hello"); -} + puts("goodbye");} It also adds an extra TAB, but it is missing the newline character after the semicolon. The following patch gets rid of the extra TAB at the beginning, but more importantly adds the missing newline at the end in a (hopefully) portable way, mentioned in http://sed.sourceforge.net/sedfaq4.html. The diff becomes this, on both Linux and NetBSD: @@ -1,4 +1,5 @@ int main(int argc, const char *argv[]) { puts("hello"); + puts("goodbye"); } Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-17t8001/t8002 (blame): add blame -L :funcname testsLibravatar Eric Sunshine1-2/+46
git-blame inherited "-L :funcname" support when "-L :funcname:file" was implemented for git-log. Add tests. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-17t8001/t8002 (blame): add blame -L testsLibravatar Eric Sunshine1-3/+101
With the exception of a couple "corner case" checks in t8003 (and some indirect tests in t4211 of -L parsing code shared by log -L), there is no systematic checking of blame -L. Add tests to check blame -L directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-17t8001/t8002 (blame): modernize styleLibravatar Eric Sunshine1-107/+114
In particular, - indent with tabs - cuddle test description and opening body quote with test_expect_foo - normalize test descriptions and case - remove whitepsace following redirection operator - use standardized filenames (such as "actual", "expected") Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-05t/annotate-tests: Use echo & cat instead of sedLibravatar Brian Gernhardt1-1/+2
The use of the sed command "1i No robots allowed" caused the version of sed in OS X to die with sed: 1: "1i "No robots allowed"\n": command i expects \ followed by text Since this command was just trying to add a single line to the beginning of the file, do the same with "echo" followed by "cat". Unbreaks t8001 and t8002 on OS X 10.6.7 Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29blame: tolerate bogus e-mail addresses a bit betterLibravatar Josh Stone1-1/+11
The names and e-mails are sanitized by fmt_ident() when creating commits, so that they do not contain "<" nor ">", and the "committer" and "author" lines in the commit object will always be in the form: ("author" | "committer") name SP "<" email ">" SP timestamp SP zone When parsing the email part out, the current code looks for SP starting from the end of the email part, but the author could obfuscate the address as "author at example dot com". We should instead look for SP followed by "<", to match the logic of the side that formats these lines. Signed-off-by: Josh Stone <jistone@redhat.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'kb/blame-author-email'Libravatar Junio C Hamano1-6/+6
* kb/blame-author-email: blame: Add option to show author email instead of name Conflicts: t/annotate-tests.sh
2010-11-24Merge branch 'en/and-cascade-tests'Libravatar Junio C Hamano1-1/+1
* en/and-cascade-tests: (25 commits) t4124 (apply --whitespace): use test_might_fail t3404: do not use 'describe' to implement test_cmp_rev t3404 (rebase -i): introduce helper to check position of HEAD t3404 (rebase -i): move comment to description t3404 (rebase -i): unroll test_commit loops t3301 (notes): use test_expect_code for clarity t1400 (update-ref): use test_must_fail t1502 (rev-parse --parseopt): test exit code from "-h" t6022 (renaming merge): chain test commands with && test-lib: introduce test_line_count to measure files tests: add missing &&, batch 2 tests: add missing && Introduce sane_unset and use it to ensure proper && chaining t7800 (difftool): add missing && t7601 (merge-pull-config): add missing && t7001 (mv): add missing && t6016 (rev-list-graph-simplify-history): add missing && t5602 (clone-remote-exec): add missing && t4026 (color): remove unneeded and unchained command t4019 (diff-wserror): add lots of missing && ... Conflicts: t/t7006-pager.sh
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-19Update test script annotate-tests.sh to handle missing/extra authorsLibravatar Kevin Ballard1-6/+6
The current script used by annotate-tests.sh (used by t8001 and t8002) fails to emit a warning if any of the expected authors never show up in the output or if authors that show up in the output were never specified as expected. Update the script to fail in both of these scenarios. Helped-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-19blame: Add option to show author email instead of nameLibravatar Kevin Ballard1-6/+6
Add a new option -e (or --show-email) to git-blame that will display the author's email instead of name on each line. This option works for both git-blame and git-annotate. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-06t/annotate-tests.sh: avoid passing a non-newline terminated file to sedLibravatar Brandon Casey1-1/+4
Some versions of sed exit non-zero if the file they are supplied is not newline terminated. Solaris's /usr/xpg4/bin/sed is one such sed. So rework this test to avoid doing so. This affects tests t8001-annotate.sh and t8002-blame.sh. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-03-06make t8001 work on Mac OS X againLibravatar Johannes Schindelin1-1/+2
The test was recently broken to expect sed to leave the incomplete line at the end without newline. POSIX says that output of the pattern space is to be followed by a newline, while GNU adds the newline back only when it was stripped when input. GNU behaviour is arguably more intuitive and nicer, but we should not depend on it. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-07Avoid ActiveState Perl IO in t800[12]Libravatar Alex Riesen1-1/+2
Use sed instead, it comes with cygwin and there is almost no chance of someone installing a sed with default CRLF lineendings by accident. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-19git-pickaxe: blame rewritten.Libravatar Junio C Hamano1-0/+1
Currently it does what git-blame does, but only faster. More importantly, its internal structure is designed to support content movement (aka cut-and-paste) more easily by allowing more than one paths to be taken from the same commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-02Fix annotate test script; notice when git-annotate fails.Libravatar Ramsay Allan Jones1-1/+2
The t8001-annotate.sh test claimed all tests pass, when in fact the git-annotate perl script failed to run! (prior to fixing the script to work with perl 5.5). Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-11tests: Set EDITOR=: and VISUAL=: globallyLibravatar Eric Wong1-1/+1
This way we don't have to remember to set it for each test; and if we forget, we won't cause interactive editors to be spawned for non-interactive tests. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19Fix t8001-annotate and t8002-blame for ActiveState PerlLibravatar Dennis Stosberg1-1/+1
There seems to be at least one implementation of Perl which requires the user to specify an extension for backup files. Reported by Alex Riesen. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-18Make t8001-annotate and t8002-blame more portableLibravatar Dennis Stosberg1-3/+1
These two tests assume that "sed" will not modify the final line of a stream if it does not end with a newline character. The assumption is not true at least for FreeBSD and Solaris 9. FreeBSD's "sed" appends a newline character; "sed" in Solaris 9 even removes the incomplete final line. This patch makes the test use perl instead. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-12annotate-tests: override VISUAL when running tests.Libravatar Mark Wooding1-1/+1
The tests hang for me waiting for Emacs with its output directed somewhere strage, because I hedged my bets and set both EDITOR and VISUAL to run Emacs. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-06annotate-blame: tests incomplete lines.Libravatar Junio C Hamano1-0/+19
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05annotate-blame test: add evil merge.Libravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05annotate/blame tests updates.Libravatar Junio C Hamano1-37/+44
This rewrites the result check code a bit. The earlier one using awk was splitting columns at any whitespace, which confused lines attributed incorrectly to the merge made by the default author "A U Thor <author@example.com>" with lines attributed to author "A". The latest test by Ryan to add the "starting from older commit" test is also included, with another older commit test. Signed-off-by: Junio C Hamano <junkio@cox.net>