Commit graph

61 commits

Author SHA1 Message Date
Beat Bolli
47c0f24539 t/annotate-tests.sh: avoid redundant use of cat
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Acked-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-16 11:08:56 -07:00
Han Young
835950bd19 blame: allow --contents to work with bare repo
The --contents option can be used with git blame to blame the file
as if it had the contents from the specified file. Since 1a3119ed
(blame: allow --contents to work with non-HEAD commit, 2023-03-24),
the --contents option can work with non-HEAD commit. However, if you
try to use --contents in a bare repository, you get the following
error:

    fatal: this operation must be run in a work tree

This is because before trying to generate a fake working tree
commit, we always call setup_work_tree(). But in a bare repo,
working tree is not available. The call to setup_work_tree is used
to prepare the reading of the blamed file in the working tree, which
isn't necessary if we are reading the contents from the specific
file instead of the file in the working tree.

Add a check in setup_scoreboard to skip setup_work_tree if we are
reading from the file specified in --contents.

This enables us to use --contents in a bare repo. This is a nice
addition on top of 1a3119ed, having a working tree to use --contents
is optional.

Add test for the --contents option with bare repo to the
annotate-tests.sh test script.

Signed-off-by: Han Young <hanyang.tony@bytedance.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-21 07:32:58 -07:00
Jacob Keller
603d0fdce2 blame: use different author name for fake commit generated by --contents
When the --contents option is used with git blame, and the contents of
the file have lines which can't be annotated by the history being
blamed, the user will see an author of "Not Committed Yet". This is
similar to the way blame handles working tree contents when blaming
without a revision.

This is slightly confusing since this data isn't the working copy and
while it is technically "not committed yet", its also coming from an
external file. Replace this author name with "External file
(--contents)" to better differentiate such lines from actual working
copy lines.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Suggested-by: Glen Choo <chooglen@google.com>
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-24 15:16:31 -07:00
Jacob Keller
1a3119ed06 blame: allow --contents to work with non-HEAD commit
The --contents option can be used with git blame to blame the file as if
it had the contents from the specified file. This is akin to copying the
contents into the working tree and then running git blame. This option
has been supported since 1cfe77333f ("git-blame: no rev means start
from the working tree file.")

The --contents option always blames the file as if it was based on the
current HEAD commit. If you try to pass a revision while using
--contents, you get the following error:

  fatal: cannot use --contents with final commit object name

This is because the blame process generates a fake working tree commit
which always uses the HEAD object as its sole parent.

Enhance fake_working_tree_commit to take the object ID to use for the
parent instead of always using the HEAD object. Then, always generate a
fake commit when we have contents provided, even if we have a final
object. Remove the check to disallow --contents and a final revision.

Note that the behavior of generating a fake working commit is still
skipped when a revision is provided but --contents is not provided.
Generating such a commit in that case would combine the currently
checked out file contents with the provided revision, which breaks
normal blame behavior and produces unexpected results.

This enables use of --contents with an arbitrary revision, rather than
forcing the use of the local HEAD commit. This makes the --contents
option significantly more flexible, as it is no longer required to check
out the working tree to the desired commit before using --contents.

Reword the documentation so that its clear that --contents can be used
with <rev>.

Add tests for the --contents option to the annotate-tests.sh test
script.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-24 12:05:22 -07:00
Junio C Hamano
3d3874d537 Merge branch 'ab/test-without-templates'
Tweak tests so that they still work when the "git init" template
did not create .git/info directory.

* ab/test-without-templates:
  tests: don't assume a .git/info for .git/info/sparse-checkout
  tests: don't assume a .git/info for .git/info/exclude
  tests: don't assume a .git/info for .git/info/refs
  tests: don't assume a .git/info for .git/info/attributes
  tests: don't assume a .git/info for .git/info/grafts
  tests: don't depend on template-created .git/branches
  t0008: don't rely on default ".git/info/exclude"
2022-07-18 13:31:55 -07:00
Ævar Arnfjörð Bjarmason
93e02b6e1e tests: don't assume a .git/info for .git/info/grafts
Change those tests that assumed that a .git/info directory would be
created for them when writing .git/info/grafts to explicitly create
the directory.

Do this using the new "TEST_CREATE_REPO_NO_TEMPLATE" facility, and use
"mkdir" instead of "mkdir -p" to assert that we don't have the
.git/info already. An exception to this is the "with grafts" test in
"t6001-rev-list-graft.sh". There we're modifying our ".git" state in a
for-loop, in lieu of refactoring that more extensively let's use
"mkdir -p" there.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-06 12:00:21 -07:00
Edmundo Carmona Antoranz
e5f5d7d42e blame: report correct number of lines in progress when using ranges
When using ranges, use the range sizes as the limit for progress
instead of the size of the full file.

Before:
$ git blame --progress builtin/blame.c > /dev/null
Blaming lines: 100% (1210/1210), done.
$ git blame --progress -L 100,120 -L 200,300 builtin/blame.c > /dev/null
Blaming lines:  10% (122/1210), done.
$

After:
$ ./git blame --progress builtin/blame.c > /dev/null
Blaming lines: 100% (1210/1210), done.
$ ./git blame --progress -L 100,120 -L 200,300 builtin/blame.c > /dev/null
Blaming lines: 100% (122/122), done.
$

Signed-off-by: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06 13:29:59 -07:00
Eric Sunshine
0c51d6b4ae t6000-t9999: detect and signal failure within loop
Failures within `for` and `while` loops can go unnoticed if not detected
and signaled manually since the loop itself does not abort when a
contained command fails, nor will a failure necessarily be detected when
the loop finishes since the loop returns the exit code of the last
command it ran on the final iteration, which may not be the command
which failed. Therefore, detect and signal failures manually within
loops using the idiom `|| return 1` (or `|| exit 1` within subshells).

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13 10:29:48 -08:00
Ævar Arnfjörð Bjarmason
f08b4013c3 blame tests: simplify userdiff driver test
Simplify the test added in 9466e3809d (blame: enable funcname blaming
with userdiff driver, 2020-11-01) to use the --author support recently
added in 999cfc4f45 (test-lib functions: add --author support to
test_commit, 2021-01-12).

We also did not need the full fortran-external-function content. Let's
cut it down to just the important parts.

I'm modifying it to demonstrate that the fortran-specific userdiff
function is in effect by adding "DO NOT MATCH ..." and "AS THE ..."
lines surrounding the "RIGHT" one.

This is to check that we're using the userdiff "fortran" driver, as
opposed to the default driver which would match on those lines as part
of the general heuristic of matching a line that doesn't begin with
whitespace.

The test had also been leaving behind a .gitattributes file for later
tests to possibly trip over, let's clean it up with
"test_when_finished".

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-08 12:19:10 -07:00
Ævar Arnfjörð Bjarmason
b269441be2 blame tests: don't rely on t/t4018/ directory
Refactor a test added in 9466e3809d (blame: enable funcname blaming
with userdiff driver, 2020-11-01) so that the blame tests don't rely
on stealing the contents of "t/t4018/fortran-external-function".

I have another patch series that'll possibly (or not) refactor that
file, but having this test inter-dependency makes things simple in any
case by making this test more readable.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-08 12:19:10 -07:00
Junio C Hamano
61b159e219 Merge branch 'pb/blame-funcname-range-userdiff'
Test fix.

* pb/blame-funcname-range-userdiff:
  annotate-tests: quote variable expansions containing path names
2021-02-05 16:40:45 -08:00
Johannes Sixt
6eaf624dea annotate-tests: quote variable expansions containing path names
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>
2021-01-30 15:15:06 -08:00
Johannes Schindelin
747f6c6805 t8*: adjust the references to the default branch name "main"
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-19 15:44:18 -08:00
Philippe Blain
9466e3809d blame: enable funcname blaming with userdiff driver
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>
2020-11-01 15:54:15 -08:00
SZEDER Gábor
a544fb08f8 blame: default to HEAD in a bare repo when no start commit is given
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>
2019-04-08 17:02:26 +09:00
Isabella Stephens
96cfa94e68 blame: prevent error if range ends past end of file
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>
2018-06-15 10:29:13 -07:00
Jeff King
7cb5f7c44d blame: fix object casting regression
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-11-24 17:07:04 -05:00
Jeff King
95a4fb0eac blame: handle --first-parent
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-09-16 09:59:05 -07:00
Jeff King
99094a7ad4 t: fix trivial &&-chain breakage
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>
2015-03-20 10:20:14 -07:00
Karsten Blees
e8d08871c9 t800[12]: work around MSys limitation
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>
2014-07-21 09:39:57 -07:00
Johannes Schindelin
e228c1736f Remove the line length limit for graft files
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-12-27 16:46:25 -08:00
Felipe Contreras
501a75a7b3 t: replace pulls with merges
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-10-31 11:12:26 -07:00
Eric Sunshine
5ce922a014 line-range: reject -L line numbers less than 1
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-06 14:48:55 -07:00
Eric Sunshine
9527604f7d t8001/t8002: blame: add tests of -L line numbers less than 1
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-06 14:48:29 -07:00
Eric Sunshine
215e76c7ff line-range: teach -L^:RE to search from start of file
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-06 14:48:02 -07:00
Eric Sunshine
1ce761a524 line-range: teach -L:RE to search from end of previous -L range
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-06 14:47:34 -07:00
Eric Sunshine
a6ac5f9864 line-range: teach -L^/RE/ to search from start of file
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-06 14:47:04 -07:00
Eric Sunshine
52f4d12648 blame: teach -L/RE/ to search from end of previous -L range
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 14:44:25 -07:00
Eric Sunshine
91b5494e18 t8001/t8002: blame: add tests of multiple -L options
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 14:33:45 -07:00
Eric Sunshine
5d57cac6ae blame: reject empty ranges -L,+0 and -L,-0
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-05 11:54:32 -07:00
Eric Sunshine
82cd7e5d3e t8001/t8002: blame: demonstrate acceptance of bogus -L,+0 and -L,-0
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-05 11:54:32 -07:00
Eric Sunshine
abba35395f blame: reject empty ranges -LX,+0 and -LX,-0
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-05 11:54:32 -07:00
Eric Sunshine
dedb9129d4 t8001/t8002: blame: demonstrate acceptance of bogus -LX,+0 and -LX,-0
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-05 11:54:32 -07:00
Eric Sunshine
164a9cf430 blame: fix -L bounds checking bug
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-05 11:54:31 -07:00
Eric Sunshine
a8fa8eca3f t8001/t8002: blame: add empty file & partial-line tests
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-05 11:54:31 -07:00
Eric Sunshine
580b4f3acf t8001/t8002: blame: demonstrate -L bounds checking bug
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-05 11:54:31 -07:00
Eric Sunshine
f350cf9ea5 t8001/t8002: blame: decompose overly-large test
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-05 11:54:30 -07:00
René Scharfe
3a4fc21a29 t8001, t8002: fix "blame -L :literal" test on NetBSD
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-05 10:43:28 -07:00
Eric Sunshine
5a9830cb71 t8001/t8002 (blame): add blame -L :funcname tests
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-17 18:02:22 -07:00
Eric Sunshine
03e15fc0b6 t8001/t8002 (blame): add blame -L tests
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-17 18:02:22 -07:00
Eric Sunshine
e37f39c134 t8001/t8002 (blame): modernize style
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>
2013-07-17 18:02:21 -07:00
Brian Gernhardt
c01bd5a29f t/annotate-tests: Use echo & cat instead of sed
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-05-05 09:24:21 -07:00
Josh Stone
9b01f0038b blame: tolerate bogus e-mail addresses a bit better
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>
2011-04-29 11:09:42 -07:00
Junio C Hamano
4ef927a995 Merge branch 'kb/blame-author-email'
* kb/blame-author-email:
  blame: Add option to show author email instead of name

Conflicts:
	t/annotate-tests.sh
2010-11-29 17:52:32 -08:00
Junio C Hamano
b3ff808b71 Merge branch 'en/and-cascade-tests'
* 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-24 15:51:49 -08:00
Jonathan Nieder
a48fcd8369 tests: add missing &&
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-11-09 11:59:49 -08:00
Kevin Ballard
27eea66b28 Update test script annotate-tests.sh to handle missing/extra authors
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-19 14:15:30 -07:00
Kevin Ballard
1b8cdce94f blame: Add option to show author email instead of name
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>
2010-10-19 12:00:28 -07:00
Brandon Casey
d8b69ecb4c t/annotate-tests.sh: avoid passing a non-newline terminated file to sed
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>
2009-05-06 11:50:44 -07:00
Johannes Schindelin
58db64f73c make t8001 work on Mac OS X again
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-03-06 17:09:53 -08:00