summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
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-05log: fix -L bounds checking bugLibravatar Eric Sunshine1-1/+1
When 12da1d1f added -L support to git-log, a broken bounds check was copied from git-blame -L which incorrectly allows -LX to extend one line past end of file without reporting an error. Instead, it generates an empty range. Fix this bug. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t4211: retire soon-to-be unimplementable testsLibravatar Eric Sunshine1-13/+0
58960978 and 99780b0a added tests which demonstrated bugs (crashes) in range-set and line-log when handed empty ranges specified via "log -LX:file" where X is one greater than the last line of the file. After these tests were added, it was realized that the ability to specify an empty range is a loophole due to a bug in -L bounds checking. That bug is slated to be fixed in a subsequent patch. Unfortunately, the closure of this loophole makes it impossible to continue checking range-set and line-log behavior with regard to empty ranges since there is no other way to specify empty ranges via the command-line. APIs of both facilities are private (file static) so there likewise is no way to test their behaviors programmatically. Consequently, retire these two tests. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05t4211: log: demonstrate -L bounds checking bugLibravatar Eric Sunshine1-0/+30
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-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-05Merge branch 'es/blame-L-breakage'Libravatar Junio C Hamano1-2/+2
* es/blame-L-breakage: t8001, t8002: fix "blame -L :literal" test on NetBSD
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-08-05Merge branch 'dn/test-reject-utf-16'Libravatar Junio C Hamano2-2/+2
* dn/test-reject-utf-16: t3900: test rejecting log message with NULs correctly Add missing test file for UTF-16.
2013-08-05t3900: test rejecting log message with NULs correctlyLibravatar Junio C Hamano1-2/+2
It is not like that our longer term desire is to someday start accept log messages with NULs in them, so it is wrong to mark a test that demonstrates "git commit" that correctly fails given such an input as "expect-failure". "git commit" should fail today, and it should fail the same way in the future given a message with NUL in it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Add missing test file for UTF-16.Libravatar Brian M. Carlson1-0/+0
The test file that the UTF-16 rejection test looks for is missing, but this went unnoticed because the test is expected to fail anyway; as a consequence, the test fails because the file containing the commit message is missing, and not because the test file contains a NUL byte. Fix this by including a sample text file containing a commit message encoded in UTF-16. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Tested-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02Merge branch 'jk/cat-file-batch-optim'Libravatar Junio C Hamano1-7/+0
* jk/cat-file-batch-optim: Revert "cat-file: split --batch input lines on whitespace"
2013-08-02Revert "cat-file: split --batch input lines on whitespace"Libravatar Junio C Hamano1-7/+0
This reverts commit c334b87b30c1464a1ab563fe1fb8de5eaf0e5bac; the update assumed that people only used the command to read from "rev-list --objects" output, whose lines begin with a 40-hex object name followed by a whitespace, but it turns out that scripts feed random extended SHA-1 expressions (e.g. "HEAD:$pathname") in which a whitespace has to be kept.
2013-08-01Merge branch 'ob/typofixes'Libravatar Junio C Hamano6-6/+6
* ob/typofixes: many small typofixes
2013-08-01Merge branch 'lf/echo-n-is-not-portable'Libravatar Junio C Hamano1-2/+2
* lf/echo-n-is-not-portable: Avoid using `echo -n` anywhere
2013-08-01Merge branch 'jx/clean-interactive'Libravatar Junio C Hamano1-2/+38
* jx/clean-interactive: git-clean: implement partial matching for selection Documentation/git-clean: fix description for range
2013-07-29many small typofixesLibravatar Ondřej Bílka6-6/+6
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Reviewed-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-29Avoid using `echo -n` anywhereLibravatar Lukas Fleischer1-2/+2
`echo -n` is non-portable. The POSIX specification says: Conforming applications that wish to do prompting without <newline> characters or that could possibly be expecting to echo a -n, should use the printf utility derived from the Ninth Edition system. Since all of the affected shell scripts use a POSIX shell shebang, replace `echo -n` invocations with printf. Signed-off-by: Lukas Fleischer <git@cryptocrack.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24Merge branch 'ml/avoid-using-grep-on-crlf-files'Libravatar Junio C Hamano3-2/+4
On systems that understand a CRLF as a line ending, tests in this script that worked on files with CRLF line endings using "grep" to extract matching lines may lose the CR at the end of lines that match, causing the actual output not to match the expected output. * ml/avoid-using-grep-on-crlf-files: test-lib.sh - define and use GREP_STRIPS_CR
2013-07-24Merge branch 'tr/line-log'Libravatar Junio C Hamano1-0/+13
Fix "log -L" command line parsing bugs. * tr/line-log: t4211: fix incorrect rebase at f8395edc (range-set: satisfy non-empty ranges invariant) line-log: fix "log -LN" crash when N is last line of file range-set: satisfy non-empty ranges invariant t4211: demonstrate crash when first -L encountered is empty range t4211: demonstrate empty -L range crash range-set: fix sort_and_merge_range_set() corner case bug
2013-07-24git-clean: implement partial matching for selectionLibravatar Jiang Xin1-2/+38
Document for interactive git-clean says: "You also could say `c` or `clean` above as long as the choice is unique". But it's not true, because only hotkey `c` and full match (`clean`) could work. Implement partial matching via find_unique function to make the document right. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24t4211: fix incorrect rebase at f8395edc (range-set: satisfy non-empty ranges ↵Libravatar Junio C Hamano1-1/+0
invariant) Wnen I rewrote "cat b.c | wc -l" into "wc -l <b.c" to squash in a suggestion on the list to this series, I screwed up subsequent rebase. Fix it up. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23line-log: fix "log -LN" crash when N is last line of fileLibravatar Eric Sunshine1-1/+1
range-set invariants are: ranges must be (1) non-empty, (2) disjoint, (3) sorted in ascending order. line_log_data_insert() breaks the non-empty invariant under the following conditions: the incoming range is empty and the pathname attached to the range has not yet been encountered. In this case, line_log_data_insert() assigns the empty range to a new line_log_data record without taking any action to ensure that the empty range is eventually folded out. Subsequent range-set functions crash or throw an assertion failure upon encountering such an anomaly. Fix this bug. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23range-set: satisfy non-empty ranges invariantLibravatar Eric Sunshine1-1/+2
range-set invariants are: ranges must be (1) non-empty, (2) disjoint, (3) sorted in ascending order. During processing, various range-set utility functions break the invariants (for instance, by adding empty ranges), with the expectation that a finalizing sort_and_merge_range_set() will restore sanity. sort_and_merge_range_set(), however, neglects to fold out empty ranges, thus it fails to satisfy the non-empty constraint. Subsequent range-set functions crash or throw an assertion failure upon encountering such an anomaly. Rectify the situation by having sort_and_merge_range_set() fold out empty ranges. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23t4211: demonstrate crash when first -L encountered is empty rangeLibravatar Eric Sunshine1-0/+5
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23t4211: demonstrate empty -L range crashLibravatar Eric Sunshine1-0/+8
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23Merge branch 'mv/merge-ff-tristate'Libravatar Junio C Hamano1-1/+1
* mv/merge-ff-tristate: t7600: fix typo in test title
2013-07-23t7600: fix typo in test titleLibravatar Junio C Hamano1-1/+1
Spotted by Ram, confirmed by Miklos. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Sync with Git 1.8.3.4Libravatar Junio C Hamano1-1/+1
2013-07-22Merge branch 'jc/name-rev-exact-ref'Libravatar Junio C Hamano1-0/+24
Corrects the longstanding sloppiness in the implementation of name-rev that conflated "we take commit-ish" and "differences between tags and commits do not matter". * jc/name-rev-exact-ref: describe: fix --contains when a tag is given as input name-rev: differentiate between tags and commits they point at describe: use argv-array name-rev: allow converting the exact object name at the tip of a ref name-ref: factor out name shortening logic from name_ref()
2013-07-22Merge branch 'es/check-mailmap'Libravatar Junio C Hamano1-0/+43
A new command to allow scripts to query the mailmap information. * es/check-mailmap: t4203: test check-mailmap command invocation builtin: add git-check-mailmap command
2013-07-22Merge branch 'jx/clean-interactive'Libravatar Junio C Hamano2-18/+493
Add "interactive" mode to "git clean". The early part to refactor relative path related helper functions looked sensible. * jx/clean-interactive: test: run testcases with POSIX absolute paths on Windows test: add t7301 for git-clean--interactive git-clean: add documentation for interactive git-clean git-clean: add ask each interactive action git-clean: add select by numbers interactive action git-clean: add filter by pattern interactive action git-clean: use a git-add-interactive compatible UI git-clean: add colors to interactive git-clean git-clean: show items of del_list in columns git-clean: add support for -i/--interactive git-clean: refactor git-clean into two phases write_name{_quoted_relative,}(): remove redundant parameters quote_path_relative(): remove redundant parameter quote.c: substitute path_relative with relative_path path.c: refactor relative_path(), not only strip prefix test: add test cases for relative_path
2013-07-22Merge branch 'hv/config-from-blob'Libravatar Junio C Hamano1-0/+70
Allow configuration data to be read from in-tree blob objects, which would help working in a bare repository and submodule updates. * hv/config-from-blob: do not die when error in config parsing of buf occurs teach config --blob option to parse config from database config: make parsing stack struct independent from actual data source config: drop cf validity check in get_next_char() config: factor out config file stack management
2013-07-22Merge branch 'jk/t0008-sigpipe-fix'Libravatar Junio C Hamano1-2/+10
Fix for recent test breakage on 'master'. * jk/t0008-sigpipe-fix: t0008: avoid SIGPIPE race condition on fifo
2013-07-22Merge branch 'db/show-ref-head'Libravatar Junio C Hamano1-0/+167
The "--head" option to "git show-ref" was only to add "HEAD" to the list of candidate refs to be filtered by the usual rules (e.g. "--heads" that only show refs under refs/heads). Change the meaning of the option to always show "HEAD" regardless of what filtering will be applied to any other ref (this is a backward incompatible change, so I may need to add an entry to the Release Notes). * db/show-ref-head: show-ref: make --head always show the HEAD ref
2013-07-22Merge branch 'es/blame-L-breakage'Libravatar Junio C Hamano3-112/+269
The refactoring made for parsing "-L" option recently to support "git log -L" seems to have broken "git blame -L X,-5" to show 5 lines leading to X. * es/blame-L-breakage: blame-options.txt: explain that -L <start> and <end> are optional blame-options.txt: place each -L option variation on its own line t8001/t8002 (blame): add blame -L :funcname tests t8001/t8002 (blame): add blame -L tests t8001/t8002 (blame): modernize style line-range: fix "blame -L X,-N" regression
2013-07-22Merge branch 'mm/diff-no-patch-synonym-to-s'Libravatar Junio C Hamano1-9/+39
"git show -s" was less discoverable than it should be. * mm/diff-no-patch-synonym-to-s: Documentation/git-log.txt: capitalize section names Documentation: move description of -s, --no-patch to diff-options.txt Documentation/git-show.txt: include common diff options, like git-log.txt diff: allow --patch & cie to override -s/--no-patch diff: allow --no-patch as synonym for -s t4000-diff-format.sh: modernize style
2013-07-22Merge branch 'jc/mailmap-case-insensitivity'Libravatar Junio C Hamano1-0/+18
The mailmap mechanism unnecessarily downcased the e-mail addresses in the output, and also ignored the human name when it is a single character name. This now has become Eric Sunshine's series, even though it still is under jc/ hierarchy. * jc/mailmap-case-insensitivity: mailmap: style fixes mailmap: debug: avoid passing NULL to fprintf() '%s' conversion specification mailmap: debug: eliminate -Wformat field precision type warning mailmap: debug: fix malformed fprintf() format conversion specification mailmap: debug: fix out-of-order fprintf() arguments mailmap: do not downcase mailmap entries t4203: demonstrate loss of uppercase characters in canonical email mailmap: do not lose single-letter names t4203: demonstrate loss of single-character name in mailmap entry
2013-07-22Merge branch 'jc/simple-add-must-be-a-no-op'Libravatar Junio C Hamano1-0/+10
This detected a mismerge of one of "add-2.0" topics to the 'jch' and 'pu' branches. * jc/simple-add-must-be-a-no-op: t2202: make sure "git add" (no args) stays a no-op
2013-07-22update URL to the marc.info mail archiveLibravatar Ondřej Bílka1-1/+1
The name marc.theaimsgroup.com is no longer active, and has migrated to marc.info. Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-21Sync with maintLibravatar Junio C Hamano1-3/+20
* maint: Update draft release notes to 1.8.3.4 t9801: git-p4: check ignore files with client spec
2013-07-21Merge branch 'dk/maint-t5150-dirname' into maintLibravatar Junio C Hamano1-1/+1
* dk/maint-t5150-dirname: tests: allow sha1's as part of the path