delta/git.git/t/annotate-tests.sh, branch sb/string-list-split-appends

blame: fix object casting regression

2015-11-24T22:07:04+00:00

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:05+00:00

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:14+00:00

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:57+00:00

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:25+00:00

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:26+00:00

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:55+00:00

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:29+00:00

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:02+00:00

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:34+00:00

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