2006-03-05 12:13:34 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
2007-07-03 07:52:14 +02:00
|
|
|
test_description='git blame'
|
2020-11-19 00:44:41 +01:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 00:44:19 +01:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
2006-03-05 12:13:34 +01:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
PROG='git blame -c'
|
2008-08-08 11:26:28 +02:00
|
|
|
. "$TEST_DIRECTORY"/annotate-tests.sh
|
2006-03-05 12:13:34 +01:00
|
|
|
|
2020-07-30 01:14:07 +02:00
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
hexsz=$(test_oid hexsz)
|
|
|
|
|
'
|
|
|
|
|
|
blame: fix segfault on untracked files
Since 3b75ee9 ("blame: allow to blame paths freshly added to the index",
2016-07-16) git blame also looks at the index to determine if there is a
file that was freshly added to the index.
cache_name_pos returns -pos - 1 in case there is no match is found, or
if the name matches, but the entry has a stage other than 0. As git
blame should work for unmerged files, it uses strcmp to determine
whether the name of the returned position matches, in which case the
file exists, but is merely unmerged, or if the file actually doesn't
exist in the index.
If the repository is empty, or if the file would lexicographically be
sorted as the last file in the repository, -cache_name_pos - 1 is
outside of the length of the active_cache array, causing git blame to
segfault. Guard against that, and die() normally to restore the old
behaviour.
Reported-by: Simon Ruderich <simon@ruderich.org>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-27 22:01:50 +02:00
|
|
|
test_expect_success 'blame untracked file in empty repo' '
|
|
|
|
|
>untracked &&
|
|
|
|
|
test_must_fail git blame untracked
|
|
|
|
|
'
|
|
|
|
|
|
2010-10-16 08:57:51 +02:00
|
|
|
PROG='git blame -c -e'
|
2013-07-17 23:25:28 +02:00
|
|
|
test_expect_success 'blame --show-email' '
|
|
|
|
|
check_count \
|
|
|
|
|
"<A@test.git>" 1 \
|
|
|
|
|
"<B@test.git>" 1 \
|
|
|
|
|
"<B1@test.git>" 1 \
|
|
|
|
|
"<B2@test.git>" 1 \
|
|
|
|
|
"<author@example.com>" 1 \
|
|
|
|
|
"<C@test.git>" 1 \
|
|
|
|
|
"<D@test.git>" 1 \
|
|
|
|
|
"<E at test dot git>" 1
|
2010-10-16 08:57:51 +02:00
|
|
|
'
|
|
|
|
|
|
2015-05-31 21:27:37 +02:00
|
|
|
test_expect_success 'setup showEmail tests' '
|
|
|
|
|
echo "bin: test number 1" >one &&
|
|
|
|
|
git add one &&
|
|
|
|
|
GIT_AUTHOR_NAME=name1 \
|
|
|
|
|
GIT_AUTHOR_EMAIL=email1@test.git \
|
|
|
|
|
git commit -m First --date="2010-01-01 01:00:00" &&
|
|
|
|
|
cat >expected_n <<-\EOF &&
|
|
|
|
|
(name1 2010-01-01 01:00:00 +0000 1) bin: test number 1
|
|
|
|
|
EOF
|
|
|
|
|
cat >expected_e <<-\EOF
|
|
|
|
|
(<email1@test.git> 2010-01-01 01:00:00 +0000 1) bin: test number 1
|
|
|
|
|
EOF
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
find_blame () {
|
|
|
|
|
sed -e 's/^[^(]*//'
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame with no options and no config' '
|
|
|
|
|
git blame one >blame &&
|
|
|
|
|
find_blame <blame >result &&
|
|
|
|
|
test_cmp expected_n result
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame with showemail options' '
|
|
|
|
|
git blame --show-email one >blame1 &&
|
|
|
|
|
find_blame <blame1 >result &&
|
|
|
|
|
test_cmp expected_e result &&
|
|
|
|
|
git blame -e one >blame2 &&
|
|
|
|
|
find_blame <blame2 >result &&
|
|
|
|
|
test_cmp expected_e result &&
|
|
|
|
|
git blame --no-show-email one >blame3 &&
|
|
|
|
|
find_blame <blame3 >result &&
|
|
|
|
|
test_cmp expected_n result
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame with showEmail config false' '
|
|
|
|
|
git config blame.showEmail false &&
|
|
|
|
|
git blame one >blame1 &&
|
|
|
|
|
find_blame <blame1 >result &&
|
|
|
|
|
test_cmp expected_n result &&
|
|
|
|
|
git blame --show-email one >blame2 &&
|
|
|
|
|
find_blame <blame2 >result &&
|
|
|
|
|
test_cmp expected_e result &&
|
|
|
|
|
git blame -e one >blame3 &&
|
|
|
|
|
find_blame <blame3 >result &&
|
|
|
|
|
test_cmp expected_e result &&
|
|
|
|
|
git blame --no-show-email one >blame4 &&
|
|
|
|
|
find_blame <blame4 >result &&
|
|
|
|
|
test_cmp expected_n result
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame with showEmail config true' '
|
|
|
|
|
git config blame.showEmail true &&
|
|
|
|
|
git blame one >blame1 &&
|
|
|
|
|
find_blame <blame1 >result &&
|
|
|
|
|
test_cmp expected_e result &&
|
|
|
|
|
git blame --no-show-email one >blame2 &&
|
|
|
|
|
find_blame <blame2 >result &&
|
|
|
|
|
test_cmp expected_n result
|
|
|
|
|
'
|
|
|
|
|
|
blame: fix alignment with --abbrev=40
The blame command internally adds 1 to any requested sha1
abbreviation length, and then subtracts it when outputting a
boundary commit. This lets regular and boundary sha1s line
up visually, but it misses one corner case.
When the requested length is 40, we bump the value to 41.
But since we only have 40 characters, that's all we can show
(fortunately the truncation is done by a printf precision
field, so it never tries to read past the end of the
buffer). So a normal sha1 shows 40 hex characters, and a
boundary sha1 shows "^" plus 40 hex characters. The result
is misaligned.
The "-l" option to show long sha1s gets around this by
skipping the "abbrev" variable entirely and just always
using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it
does mean that boundary commits only have 39 characters
printed. This is somewhat odd, but it does look good
visually: the results are aligned and left-justified. The
alternative would be to allocate an extra column that would
contain either an extra space or the "^" boundary marker.
As this is by definition the human-readable view, it's
probably not that big a deal either way (and of course
--porcelain, etc, correctly produce correct 40-hex sha1s).
But for consistency, this patch teaches --abbrev=40 to
produce the same output as "-l" (always left-aligned, with
40-hex for normal sha1s, and "^" plus 39-hex for
boundaries).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-06 05:17:40 +01:00
|
|
|
test_expect_success 'set up abbrev tests' '
|
|
|
|
|
test_commit abbrev &&
|
|
|
|
|
sha1=$(git rev-parse --verify HEAD) &&
|
|
|
|
|
check_abbrev () {
|
tests: fix broken &&-chains in `{...}` groups
The top-level &&-chain checker built into t/test-lib.sh causes tests to
magically exit with code 117 if the &&-chain is broken. However, it has
the shortcoming that the magic does not work within `{...}` groups,
`(...)` subshells, `$(...)` substitutions, or within bodies of compound
statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed`
partly fills in the gap by catching broken &&-chains in `(...)`
subshells, but bugs can still lurk behind broken &&-chains in the other
cases.
Fix broken &&-chains in `{...}` groups in order to reduce the number of
possible lurking bugs.
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-09 06:11:08 +01:00
|
|
|
expect=$1 && shift &&
|
blame: fix alignment with --abbrev=40
The blame command internally adds 1 to any requested sha1
abbreviation length, and then subtracts it when outputting a
boundary commit. This lets regular and boundary sha1s line
up visually, but it misses one corner case.
When the requested length is 40, we bump the value to 41.
But since we only have 40 characters, that's all we can show
(fortunately the truncation is done by a printf precision
field, so it never tries to read past the end of the
buffer). So a normal sha1 shows 40 hex characters, and a
boundary sha1 shows "^" plus 40 hex characters. The result
is misaligned.
The "-l" option to show long sha1s gets around this by
skipping the "abbrev" variable entirely and just always
using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it
does mean that boundary commits only have 39 characters
printed. This is somewhat odd, but it does look good
visually: the results are aligned and left-justified. The
alternative would be to allocate an extra column that would
contain either an extra space or the "^" boundary marker.
As this is by definition the human-readable view, it's
probably not that big a deal either way (and of course
--porcelain, etc, correctly produce correct 40-hex sha1s).
But for consistency, this patch teaches --abbrev=40 to
produce the same output as "-l" (always left-aligned, with
40-hex for normal sha1s, and "^" plus 39-hex for
boundaries).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-06 05:17:40 +01:00
|
|
|
echo $sha1 | cut -c 1-$expect >expect &&
|
|
|
|
|
git blame "$@" abbrev.t >actual &&
|
|
|
|
|
perl -lne "/[0-9a-f]+/ and print \$&" <actual >actual.sha &&
|
|
|
|
|
test_cmp expect actual.sha
|
|
|
|
|
}
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame --abbrev=<n> works' '
|
|
|
|
|
# non-boundary commits get +1 for alignment
|
|
|
|
|
check_abbrev 31 --abbrev=30 HEAD &&
|
|
|
|
|
check_abbrev 30 --abbrev=30 ^HEAD
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame -l aligns regular and boundary commits' '
|
2020-07-30 01:14:07 +02:00
|
|
|
check_abbrev $hexsz -l HEAD &&
|
|
|
|
|
check_abbrev $((hexsz - 1)) -l ^HEAD
|
blame: fix alignment with --abbrev=40
The blame command internally adds 1 to any requested sha1
abbreviation length, and then subtracts it when outputting a
boundary commit. This lets regular and boundary sha1s line
up visually, but it misses one corner case.
When the requested length is 40, we bump the value to 41.
But since we only have 40 characters, that's all we can show
(fortunately the truncation is done by a printf precision
field, so it never tries to read past the end of the
buffer). So a normal sha1 shows 40 hex characters, and a
boundary sha1 shows "^" plus 40 hex characters. The result
is misaligned.
The "-l" option to show long sha1s gets around this by
skipping the "abbrev" variable entirely and just always
using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it
does mean that boundary commits only have 39 characters
printed. This is somewhat odd, but it does look good
visually: the results are aligned and left-justified. The
alternative would be to allocate an extra column that would
contain either an extra space or the "^" boundary marker.
As this is by definition the human-readable view, it's
probably not that big a deal either way (and of course
--porcelain, etc, correctly produce correct 40-hex sha1s).
But for consistency, this patch teaches --abbrev=40 to
produce the same output as "-l" (always left-aligned, with
40-hex for normal sha1s, and "^" plus 39-hex for
boundaries).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-06 05:17:40 +01:00
|
|
|
'
|
|
|
|
|
|
2020-07-30 01:14:07 +02:00
|
|
|
test_expect_success 'blame --abbrev with full length behaves like -l' '
|
|
|
|
|
check_abbrev $hexsz --abbrev=$hexsz HEAD &&
|
|
|
|
|
check_abbrev $((hexsz - 1)) --abbrev=$hexsz ^HEAD
|
blame: fix alignment with --abbrev=40
The blame command internally adds 1 to any requested sha1
abbreviation length, and then subtracts it when outputting a
boundary commit. This lets regular and boundary sha1s line
up visually, but it misses one corner case.
When the requested length is 40, we bump the value to 41.
But since we only have 40 characters, that's all we can show
(fortunately the truncation is done by a printf precision
field, so it never tries to read past the end of the
buffer). So a normal sha1 shows 40 hex characters, and a
boundary sha1 shows "^" plus 40 hex characters. The result
is misaligned.
The "-l" option to show long sha1s gets around this by
skipping the "abbrev" variable entirely and just always
using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it
does mean that boundary commits only have 39 characters
printed. This is somewhat odd, but it does look good
visually: the results are aligned and left-justified. The
alternative would be to allocate an extra column that would
contain either an extra space or the "^" boundary marker.
As this is by definition the human-readable view, it's
probably not that big a deal either way (and of course
--porcelain, etc, correctly produce correct 40-hex sha1s).
But for consistency, this patch teaches --abbrev=40 to
produce the same output as "-l" (always left-aligned, with
40-hex for normal sha1s, and "^" plus 39-hex for
boundaries).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-06 05:17:40 +01:00
|
|
|
'
|
|
|
|
|
|
2020-07-30 01:14:07 +02:00
|
|
|
test_expect_success '--no-abbrev works like --abbrev with full length' '
|
|
|
|
|
check_abbrev $hexsz --no-abbrev
|
2017-01-06 05:18:08 +01:00
|
|
|
'
|
|
|
|
|
|
2018-10-23 03:13:42 +02:00
|
|
|
test_expect_success '--exclude-promisor-objects does not BUG-crash' '
|
|
|
|
|
test_must_fail git blame --exclude-promisor-objects one
|
|
|
|
|
'
|
|
|
|
|
|
2020-07-22 00:50:20 +02:00
|
|
|
test_expect_success 'blame with uncommitted edits in partial clone does not crash' '
|
|
|
|
|
git init server &&
|
|
|
|
|
echo foo >server/file.txt &&
|
|
|
|
|
git -C server add file.txt &&
|
|
|
|
|
git -C server commit -m file &&
|
|
|
|
|
|
|
|
|
|
git clone --filter=blob:none "file://$(pwd)/server" client &&
|
|
|
|
|
echo bar >>client/file.txt &&
|
|
|
|
|
git -C client blame file.txt
|
|
|
|
|
'
|
|
|
|
|
|
2006-03-05 12:13:34 +01:00
|
|
|
test_done
|