summaryrefslogtreecommitdiff
path: root/t/t8003-blame-corner-cases.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19t8*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-3/+3
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-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
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-08-19Merge branch 'jk/blame-coalesce-fix'Libravatar Junio C Hamano1-9/+19
When given more than one target line ranges, "git blame -La,b -Lc,d" was over-eager to coalesce groups of original lines and showed incorrect results, which has been corrected. * jk/blame-coalesce-fix: blame: only coalesce lines that are adjacent in result t8003: factor setup out of coalesce test t8003: check output of coalesced blame
2020-08-13blame: only coalesce lines that are adjacent in resultLibravatar Jeff King1-0/+9
After blame has finished but before we produce any output, we coalesce groups of lines that were adjacent in the original suspect (which may have been split apart by lines in intermediate commits which went away). However, this can cause incorrect output if the lines are not also adjacent in the result. For instance, the case in t8003 has: ABC DEF which becomes ABC SPLIT DEF Blaming only lines 1 and 3 in the result yields two blame groups (one for each line) that were adjacent in the original. That's enough for us to coalesce them into a single group, but that loses information: our output routines assume they're adjacent in the result as well, and we output: <oid> 1) ABC <oid> 2) SPLIT This is nonsense for two reasons: - we were asked about line 3, not line 2; we should not output the SPLIT line at all - commit <oid> did not touch the SPLIT line at all! We found the correct blame for line 3, but the bug is actually in the output stage, which is showing the wrong line number and content from the final file. We can fix this by only coalescing when both the suspect and result lines are adjacent. That fixes this bug, but keeps coalescing in cases where want it (e.g., the existing test in t8003 where SPLIT goes away, and the lines really are adjacent in the result). Reported-by: Nuthan Munaiah <nm6061@rit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13t8003: factor setup out of coalesce testLibravatar Jeff King1-6/+10
In preparation for adding more tests of blame's coalesce code, let's split the setup out from the first test, and give each of the commits a more meaningful name: - $orig for the original source that added the lines - $split for the version where they are split apart - $final for the final version that re-joins them That's not strictly necessary, but makes the follow-on tests less brittle than relying on HEAD^, etc, to name the commits. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13t8003: check output of coalesced blameLibravatar Jeff King1-7/+4
Commit f0cbe742f4 (blame: add a test to cover blame_coalesce(), 2019-06-20) added a test case where blame can usefully coalesce two groups of lines. But since it relies on the normal blame output, it only exercises the code and can't tell whether the lines were actually joined into a single group. However, by using --porcelain output, we can see how git-blame considers the groupings (and likewise how the coalescing might have a real user-visible impact for a tool that uses the porcelain-output groupings). This lets us confirm that we are indeed coalescing correctly (and the fact that this test case requires coalescing can be verified by dropping the call to blame_coalesce(), causing the test to fail). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30t8003: make hash size independentLibravatar brian m. carlson1-2/+1
One assertion in this test invokes git with core.abbrev set to "40". Since we're expecting the full hash length, use test_oid to look up the full hash length for the hash in use. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24t: drop debug `cat` callsLibravatar Martin Ågren1-1/+0
We `cat` files, but don't inspect or grab the contents in any way. Unlike in an earlier commit, there is no reason to suspect that these files could be missing, so `cat`-ing them is just wasted effort. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20blame: add a test to cover blame_coalesce()Libravatar Barret Rhoden1-0/+36
Signed-off-by: Barret Rhoden <brho@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-15blame: prevent error if range ends past end of fileLibravatar Isabella Stephens1-4/+8
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>
2016-09-15i18n: blame: mark error messages for translationLibravatar Vasco Almeida1-2/+2
Mark error messages for translation passed to die() function. Change "Cannot" to lowercase following the usual style. Reflect changes to test by using test_i18ngrep. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-18t/t8003-blame-corner-cases.sh: Use here documentsLibravatar Mike Hommey1-17/+17
Somehow, this test was using: { echo A echo B } > file block to feed file contents. This changes those to the form most common in git test scripts: cat >file <<-\EOF A B EOF Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-18blame: allow to blame paths freshly added to the indexLibravatar Mike Hommey1-0/+45
When blaming files, changes in the work tree are taken into account and displayed as being "Not Committed Yet". However, when blaming a file that is not known to the current HEAD, git blame fails with `no such path 'foo' in HEAD`, even when the file was git add'ed. Allowing such a blame is useful when the new file added to the index (not yet committed) was created by renaming an existing file. It also is useful when the new file was created from pieces already in HEAD, moved or copied from other files and blaming with copy detection (i.e. "-C"). Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-29Merge branch 'tb/blame-force-read-cache-to-workaround-safe-crlf' into maintLibravatar Junio C Hamano1-0/+14
When running "git blame $path" with unnormalized data in the index for the path, the data in the working tree was blamed, even though "git add" would not have changed what is already in the index, due to "safe crlf" that disables the line-end conversion. It has been corrected. * tb/blame-force-read-cache-to-workaround-safe-crlf: correct blame for files commited with CRLF
2016-04-05correct blame for files commited with CRLFLibravatar Torsten Bögershausen1-0/+14
git blame reports lines as not "Not Committed Yet" when they have CRLF in the index, CRLF in the worktree and core.autocrlf is true. Since commit c4805393 (autocrlf: Make it work also for un-normalized repositories, 2010-05-12), files that have CRLF in the index are not normalized at commit when core.autocrl is set. Add a call to read_cache() early in fake_working_tree_commit(), before calling convert_to_git(). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08t/t8003-blame-corner-cases.sh: use the $( ... ) construct for command ↵Libravatar Elia Pinto1-2/+2
substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-05Merge branch 'tb/blame-resurrect-convert-to-git' into maintLibravatar Junio C Hamano1-3/+15
Some time ago, "git blame" (incorrectly) lost the convert_to_git() call when synthesizing a fake "tip" commit that represents the state in the working tree, which broke folks who record the history with LF line ending to make their project portabile across platforms while terminating lines in their working tree files with CRLF for their platform. * tb/blame-resurrect-convert-to-git: blame: CRLF in the working tree and LF in the repo
2015-05-11Merge branch 'tb/blame-resurrect-convert-to-git'Libravatar Junio C Hamano1-3/+15
Some time ago, "git blame" (incorrectly) lost the convert_to_git() call when synthesizing a fake "tip" commit that represents the state in the working tree, which broke folks who record the history with LF line ending to make their project portabile across platforms while terminating lines in their working tree files with CRLF for their platform. * tb/blame-resurrect-convert-to-git: blame: CRLF in the working tree and LF in the repo
2015-05-03blame: CRLF in the working tree and LF in the repoLibravatar Torsten Bögershausen1-3/+15
A typical setup under Windows is to set core.eol to CRLF, and text files are marked as "text" in .gitattributes, or core.autocrlf is set to true. After 4d4813a5 "git blame" no longer works as expected for such a set-up. Every line is annotated as "Not Committed Yet", even though the working directory is clean. This is because the commit removed the conversion in blame.c for all files, with or without CRLF in the repo. Having files with CRLF in the repo and core.autocrlf=input is a temporary situation, and the files, if committed as is, will be normalized in the repo, which _will_ be a notable change. Blaming them with "Not Committed Yet" is the right result. Revert commit 4d4813a5 which was a misguided attempt to "solve" a non-problem. Add two test cases in t8003 to verify the correct CRLF conversion. Suggested-By: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-4/+4
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>
2014-05-08blame: correctly handle files regardless of autocrlfLibravatar brian m. carlson1-0/+9
If a file contained CRLF line endings in a repository with core.autocrlf=input, then blame always marked lines as "Not Committed Yet", even if they were unmodified. Don't attempt to convert the line endings when creating the fake commit so that blame works correctly regardless of the autocrlf setting. Reported-by: Ephrim Khong <dr.khong@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28Refactor parse_locLibravatar Bo Yang1-0/+6
We want to use the same style of -L n,m argument for 'git log -L' as for git-blame. Refactor the argument parsing of the range arguments from builtin/blame.c to the (new) file that will hold the 'git log -L' logic. To accommodate different data structures in blame and log -L, the file contents are abstracted away; parse_range_arg takes a callback that it uses to get the contents of a line of the (notional) file. The new test is for a case that made me pause during debugging: the 'blame -L with invalid end' test was the only one that noticed an outright failure to parse the end *at all*. So make a more explicit test for that. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-13t800?-blame.sh: retitle uniquelyLibravatar Michael J Gruber1-0/+188
Currently we have three test files matching t800?-blame.sh. Rename the latter two to make it easier to spot where additions would go. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>