git/t/annotate-tests.sh, branch jch

t/annotate-tests.sh: avoid redundant use of cat

2024-03-16T18:08:56Z

Signed-off-by: Beat Bolli Acked-by: Taylor Blau Signed-off-by: Junio C Hamano

blame: allow --contents to work with bare repo

2023-07-21T14:32:58Z

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

blame: use different author name for fake commit generated by --contents

2023-04-24T22:16:31Z

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 Suggested-by: Glen Choo Signed-off-by: Jacob Keller Signed-off-by: Junio C Hamano

blame: allow --contents to work with non-HEAD commit

2023-03-24T19:05:22Z

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 1cfe77333f27 ("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 . Add tests for the --contents option to the annotate-tests.sh test script. Signed-off-by: Jacob Keller Signed-off-by: Junio C Hamano

Merge branch 'ab/test-without-templates'

2022-07-18T20:31:55Z

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"

tests: don't assume a .git/info for .git/info/grafts

2022-06-06T19:00:21Z

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

blame: report correct number of lines in progress when using ranges

2022-04-06T20:29:59Z

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

t6000-t9999: detect and signal failure within loop

2021-12-13T18:29:48Z

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

blame tests: simplify userdiff driver test

2021-04-08T19:19:10Z

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

blame tests: don't rely on t/t4018/ directory

2021-04-08T19:19:10Z

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