git/t/annotate-tests.sh, branch v2.4.4

t: fix trivial &&-chain breakage

2015-03-20T17:20:14Z

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 Signed-off-by: Junio C Hamano

t800[12]: work around MSys limitation

2014-07-21T16:39:57Z

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 Author: Stepan Kasal Signed-off-by: Johannes Schindelin Signed-off-by: Stepan Kasal Signed-off-by: Junio C Hamano

Remove the line length limit for graft files

2013-12-28T00:46:25Z

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 Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

t: replace pulls with merges

2013-10-31T18:12:26Z

This is what the code intended. No functional changes. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

line-range: reject -L line numbers less than 1

2013-08-06T21:48:55Z

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 Signed-off-by: Junio C Hamano

t8001/t8002: blame: add tests of -L line numbers less than 1

2013-08-06T21:48:29Z

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 Signed-off-by: Junio C Hamano

line-range: teach -L^:RE to search from start of file

2013-08-06T21:48:02Z

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 Signed-off-by: Junio C Hamano

line-range: teach -L:RE to search from end of previous -L range

2013-08-06T21:47:34Z

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 Signed-off-by: Junio C Hamano

line-range: teach -L^/RE/ to search from start of file

2013-08-06T21:47:04Z

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 argument of -L,. The argument, as usual, is relative to . Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

blame: teach -L/RE/ to search from end of previous -L range

2013-08-06T21:44:25Z

Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano