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

blame: prevent error if range ends past end of file

2018-06-15T17:29:13Z

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

blame: fix object casting regression

2015-11-24T22:07:04Z

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 ] Signed-off-by: Jeff King

blame: handle --first-parent

2015-09-16T16:59:05Z

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

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