summaryrefslogtreecommitdiff
path: root/t/t4013-diff-various.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-02-05Merge branch 'so/log-diff-merge'Libravatar Junio C Hamano1-1/+10
"git log" learned a new "--diff-merges=<how>" option. * so/log-diff-merge: (32 commits) t4013: add tests for --diff-merges=first-parent doc/git-show: include --diff-merges description doc/rev-list-options: document --first-parent changes merges format doc/diff-generate-patch: mention new --diff-merges option doc/git-log: describe new --diff-merges options diff-merges: add '--diff-merges=1' as synonym for 'first-parent' diff-merges: add old mnemonic counterparts to --diff-merges diff-merges: let new options enable diff without -p diff-merges: do not imply -p for new options diff-merges: implement new values for --diff-merges diff-merges: make -m/-c/--cc explicitly mutually exclusive diff-merges: refactor opt settings into separate functions diff-merges: get rid of now empty diff_merges_init_revs() diff-merges: group diff-merge flags next to each other inside 'rev_info' diff-merges: split 'ignore_merges' field diff-merges: fix -m to properly override -c/--cc t4013: add tests for -m failing to override -c/--cc t4013: support test_expect_failure through ':failure' magic diff-merges: revise revs->diff flag handling diff-merges: handle imply -p on -c/--cc logic for log.c ...
2020-12-21t4013: add tests for --diff-merges=first-parentLibravatar Sergey Organov1-0/+2
This new option provides essential new functionality, changing diff output to first parent only, without changing history traversal mode, so it deserves its own test. As we do it, add additional test that --diff-merges=first-parent by itself doesn't imply -p and only outputs diffs for merge commits. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21diff-merges: fix -m to properly override -c/--ccLibravatar Sergey Organov1-2/+2
Logically, -m, -c, --cc specify 3 different formats for representing merge commits, yet -m doesn't in fact override -c or --cc, that makes no sense. Fix -m to properly override -c/--cc, and change the tests accordingly. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21t4013: add tests for -m failing to override -c/--ccLibravatar Sergey Organov1-0/+2
Logically, -m, -c, --cc specify 3 different formats for representing merge commits, yet -m doesn't in fact override -c or --cc, that makes no sense. Add 2 expected to fail tests that demonstrate the problem. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21t4013: support test_expect_failure through ':failure' magicLibravatar Sergey Organov1-1/+6
Add support to be able to specify expected failure, through :failure magic, like this: :failure cmd args Signed-off-by: Sergey Organov <sorganov@gmail.com> 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-11-02Merge branch 'mk/diff-ignore-regex'Libravatar Junio C Hamano1-0/+41
"git diff" family of commands learned the "-I<regex>" option to ignore hunks whose changed lines all match the given pattern. * mk/diff-ignore-regex: diff: add -I<regex> that ignores matching changes merge-base, xdiff: zero out xpparam_t structures
2020-10-20diff: add -I<regex> that ignores matching changesLibravatar Michał Kępień1-0/+41
Add a new diff option that enables ignoring changes whose all lines (changed, removed, and added) match a given regular expression. This is similar to the -I/--ignore-matching-lines option in standalone diff utilities and can be used e.g. to ignore changes which only affect code comments or to look for unrelated changes in commits containing a large number of automatically applied modifications (e.g. a tree-wide string replacement). The difference between -G/-S and the new -I option is that the latter filters output on a per-change basis. Use the 'ignore' field of xdchange_t for marking a change as ignored or not. Since the same field is used by --ignore-blank-lines, identical hunk emitting rules apply for --ignore-blank-lines and -I. These two options can also be used together in the same git invocation (they are complementary to each other). Rename xdl_mark_ignorable() to xdl_mark_ignorable_lines(), to indicate that it is logically a "sibling" of xdl_mark_ignorable_regex() rather than its "parent". Signed-off-by: Michał Kępień <michal@isc.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31Merge branch 'dd/diff-customize-index-line-abbrev'Libravatar Junio C Hamano1-21/+42
The output from the "diff" family of the commands had abbreviated object names of blobs involved in the patch, but its length was not affected by the --abbrev option. Now it is. * dd/diff-customize-index-line-abbrev: diff: index-line: respect --abbrev in object's name t4013: improve diff-post-processor logic
2020-08-21diff: index-line: respect --abbrev in object's nameLibravatar Đoàn Trần Công Danh1-0/+3
A handful of Git's commands respect `--abbrev' for customizing length of abbreviation of object names. For diff-family, Git supports 2 different options for 2 different purposes, `--full-index' for showing diff-patch object's name in full, and `--abbrev' to customize the length of object names in diff-raw and diff-tree header lines, without any options to customise the length of object names in diff-patch format. When working with diff-patch format, we only have two options, either full index, or default abbrev length. Although, that behaviour is documented, it doesn't stop users from trying to use `--abbrev' with the hope of customising diff-patch's objects' name's abbreviation. Let's allow the blob object names shown on the "index" line to be abbreviated to arbitrary length given via the "--abbrev" option. To preserve backward compatibility with old script that specify both `--full-index' and `--abbrev', always show full object id if `--full-index' is specified. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21t4013: improve diff-post-processor logicLibravatar brian m. carlson1-21/+39
From 72f936b1 (t4013: make test hash independent, 2020-02-07), we started to adjust metadata of git-diff's output in order to ignore uninteresting metadata which is dependent of underlying hash algorithm. However, we forgot to special case all-zero object names, which is special for missing objects, in consequence, we could't catch possible future bugs where object names is all-zeros including but not limited to: * show intend-to-add entry * deleted entry * diff between index and working tree with new file We also mistakenly munged file-modes as if they were object names abbreviated to 6 hexadecimal digits. In addition, in the upcoming change, we would like to test for customizing the length of abbreviated blob objects on the index line, which is not supported by current diff-processor logic. Let's fix the bug for all-zero object names, and file modes. While we're at it, support abbreviation of object names up to 16 bytes. Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-17Merge branch 'so/log-diff-merges-opt'Libravatar Junio C Hamano1-0/+2
Earlier, to countermand the implicit "-m" option when the "--first-parent" option is used with "git log", we added the "--[no-]diff-merges" option in the jk/log-fp-implies-m topic. To leave the door open to allow the "--diff-merges" option to take values that instructs how patches for merge commits should be computed (e.g. "cc"? "-p against first parent?"), redefine "--diff-merges" to take non-optional value, and implement "off" that means the same thing as "--no-diff-merges". * so/log-diff-merges-opt: t/t4013: add test for --diff-merges=off doc/git-log: describe --diff-merges=off revision: change "--diff-merges" option to require parameter
2020-08-17Merge branch 'jk/log-fp-implies-m'Libravatar Junio C Hamano1-0/+1
"git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. * jk/log-fp-implies-m: doc/git-log: clarify handling of merge commit diffs doc/git-log: move "-t" into diff-options list doc/git-log: drop "-r" diff option doc/git-log: move "Diff Formatting" from rev-list-options log: enable "-m" automatically with "--first-parent" revision: add "--no-diff-merges" option to counteract "-m" log: drop "--cc implies -m" logic
2020-08-11t/t4013: add test for --diff-merges=offLibravatar Sergey Organov1-0/+2
Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Revert "fmt-merge-msg: stop treating `master` specially"Libravatar Junio C Hamano1-2/+2
This reverts commit 489947cee5095b168cbac111ff7bd1eadbbd90dd, which stopped treating merges into the 'master' branch as special when preparing the default merge message. As the goal was not to have any single branch designated as special, it solved it by leaving the "into <branchname>" at the end of the title of the default merge message for any and all branches. An obvious and easy alternative to treat everybody equally could have been to remove it for every branch, but that involves loss of information. We'll introduce a new mechanism to let end-users specify merges into which branches would omit the "into <branchname>" from the title of the default merge message, and make the mechanism, when unconfigured, treat the traditional 'master' special again, so all the changes to the tests we made earlier will become unnecessary, as these tests will be run without configuring the said new mechanism. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29revision: add "--no-diff-merges" option to counteract "-m"Libravatar Jeff King1-0/+1
The "-m" option sets revs->ignore_merges to "0", but there's no way to undo it. This probably isn't something anybody overly cares about, since "1" is already the default, but it will serve as an escape hatch when we flip the default for ignore_merges to "0" in more situations. We'll also add a few extra niceties: - initialize the value to "-1" to indicate "not set", and then resolve it to the normal 0/1 bool in setup_revisions(). This lets any tweak functions, as well as setup_revisions() itself, avoid clobbering the user's preference (which until now they couldn't actually express). - since we now have --no-diff-merges, let's add the matching --diff-merges, which is just a synonym for "-m". Then we don't even need to document --no-diff-merges separately; it countermands the long form of "-m" in the usual way. The new test shows that this behaves just the same as the current behavior without "-m". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-23fmt-merge-msg: stop treating `master` speciallyLibravatar Johannes Schindelin1-2/+2
In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28Merge branch 'tb/diff-tree-with-notes'Libravatar Junio C Hamano1-0/+12
"git diff-tree --pretty --notes" used to hit an assertion failure, as it forgot to initialize the notes subsystem. * tb/diff-tree-with-notes: diff-tree.c: load notes machinery when required
2020-04-20diff-tree.c: load notes machinery when requiredLibravatar Taylor Blau1-0/+12
Since its introduction in 7249e91 (revision.c: support --notes command-line option, 2011-03-29), combining '--notes' with any option that causes us to format notes (e.g., '--pretty', '--format="%N"', etc) results in a failed assertion at runtime. $ git rev-list HEAD | git diff-tree --stdin --pretty=medium --notes commit 8f3d9f354286745c751374f5f1fcafee6b3f3136 git: notes.c:1308: format_display_notes: Assertion `display_notes_trees' failed. Aborted This failure is due to diff-tree not calling 'load_display_notes' to initialize the notes machinery. Ordinarily, this failure isn't triggered, because it requires passing both '--notes' and another of the above mentioned options. In the case of '--pretty', for example, we set 'opt->verbose_header', causing 'show_log()' to eventually call 'format_display_notes()', which expects a non-NULL 'display_note_trees'. Without initializing the notes machinery, 'display_note_trees' remains NULL, and thus triggers an assertion failure. Fix this by initializing the notes machinery after parsing our options, and harden this behavior against regression with a test in t4013. (Note that the added ref in this test requires updating two unrelated tests which use 'log --all', and thus need to learn about the new refs). Reported-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-07t4013: make test hash independentLibravatar brian m. carlson1-6/+38
This test produces a large number of diff formats and compares the output with test files that have content specific to SHA-1. Since we are more interested in the format of the diffs, and not their specific values, which are tested elsewhere, add a function which uses sed to transform these specific object IDs into generic ones of the right size, which we can then compare. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t: use LF variable defined in the test harnessLibravatar Junio C Hamano1-3/+0
A few test scripts assign a single LF to $LF, but that is already given by test-lib.sh to everybody. Remove the unnecessary reassignment. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-30Merge branch 'nd/diff-parseopt'Libravatar Junio C Hamano1-0/+2
A brown-paper-bag bugfix to a change already in 'master'. * nd/diff-parseopt: parse-options: check empty value in OPT_INTEGER and OPT_ABBREV diff-parseopt: restore -U (no argument) behavior diff-parseopt: correct variable types that are used by parseopt
2019-05-29diff-parseopt: restore -U (no argument) behaviorLibravatar Nguyễn Thái Ngọc Duy1-0/+2
Before d473e2e0e8 (diff.c: convert -U|--unified, 2019-01-27), -U and --unified are implemented with a custom parser opt_arg() in diff.c. I didn't check this code carefully and not realize that it's the equivalent of PARSE_OPT_NONEG | PARSE_OPT_OPTARG. In other words, if -U is specified without any argument, the option should be accepted, and the default value should be used. Without PARSE_OPT_OPTARG, parse_options() will reject this case and cause a regression. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24combine-diff: treat --dirstat like --statLibravatar Jeff King1-0/+1
Currently "--cc --dirstat" will show nothing for a merge. Like --shortstat and --summary in the previous two patches, it probably makes sense to treat it like we do --stat, and show a stat against the first-parent. This case is less obviously correct than for --shortstat and --summary, as those are basically variants of --stat themselves. It's possible we could develop a multi-parent combined dirstat format, in which case we might regret defining this first-parent behavior. But the same could be said for --stat, and in the 12+ years of it showing first-parent stats, nobody has complained. So showing the first-parent dirstat is at least _useful_, and if we later develop a clever multi-parent stat format, we'd probably have to deal with --stat anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24combine-diff: treat --summary like --statLibravatar Jeff King1-0/+7
Currently "--cc --summary" on a merge shows nothing. Since we show "--cc --stat" as a stat against the first parent, and because --summary is typically used in combination with --stat, it makes sense to treat them both the same way. Note that we have to tweak t4013's setup a bit to test this case, as the existing merges do not have any --summary results against their first parent. But since the merge at the tip of 'master' does add and remove files with respect to the second parent, we can just make a reversed doppelganger merge where the parents are swapped. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24combine-diff: treat --shortstat like --statLibravatar Jeff King1-0/+1
The --stat of a combined diff is defined as the first-parent stat, going all the way back to 965f803c32 (combine-diff: show diffstat with the first parent., 2006-04-17). Naturally, we gave --numstat the same treatment in 74e2abe5b7 (diff --numstat, 2006-10-12). But --shortstat, which is really just the final line of --stat, does nothing, which produces confusing results: $ git show --oneline --stat eab7584e37 eab7584e37 Merge branch 'en/show-ref-doc-fix' Documentation/git-show-ref.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git show --oneline --shortstat eab7584e37 eab7584e37 Merge branch 'en/show-ref-doc-fix' [nothing! We'd expect to see the "1 file changed..." line] This patch teaches combine-diff to treats the two formats identically. Reported-by: David Turner <novalis@novalis.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-20tests: send "bug in the test script" errors to the script's stderrLibravatar SZEDER Gábor1-1/+1
Some of the functions in our test library check that they were invoked properly with conditions like this: test "$#" = 2 || error "bug in the test script: not 2 parameters to test-expect-success" If this particular condition is triggered, then 'error' will abort the whole test script with a bold red error message [1] right away. However, under certain circumstances the test script will be aborted completely silently, namely if: - a similar condition in a test helper function like 'test_line_count' is triggered, - which is invoked from the test script's "main" shell [2], - and the test script is run manually (i.e. './t1234-foo.sh' as opposed to 'make t1234-foo.sh' or 'make test') [3] - and without the '--verbose' option, because the error message is printed from within 'test_eval_', where standard output is redirected either to /dev/null or to a log file. The only indication that something is wrong is that not all tests in the script are executed and at the end of the test script's output there is no "# passed all N tests" message, which are subtle and can easily go unnoticed, as I had to experience myself. Send these "bug in the test script" error messages directly to the test scripts standard error and thus to the terminal, so those bugs will be much harder to overlook. Instead of updating all ~20 such 'error' calls with a redirection, let's add a BUG() function to 'test-lib.sh', wrapping an 'error' call with the proper redirection and also including the common prefix of those error messages, and convert all those call sites [4] to use this new BUG() function instead. [1] That particular error message from 'test_expect_success' is printed in color only when running with or without '--verbose'; with '--tee' or '--verbose-log' the error is printed without color, but it is printed to the terminal nonetheless. [2] If such a condition is triggered in a subshell of a test, then 'error' won't be able to abort the whole test script, but only the subshell, which in turn causes the test to fail in the usual way, indicating loudly and clearly that something is wrong. [3] Well, 'error' aborts the test script the same way when run manually or by 'make' or 'prove', but both 'make' and 'prove' pay attention to the test script's exit status, and even a silently aborted test script would then trigger those tools' usual noticable error messages. [4] Strictly speaking, not all those 'error' calls need that redirection to send their output to the terminal, see e.g. 'test_expect_success' in the opening example, but I think it's better to be consistent. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29tests: fix non-portable "${var:-"str"}" constructLibravatar Ævar Arnfjörð Bjarmason1-1/+1
On both AIX 7200-00-01-1543 and FreeBSD 11.2-RELEASE-p2 the "${var:-"str"}" syntax means something different than what it does under the bash or dash shells. Both will consider the start of the new unescaped quotes to be a new argument to test_expect_success, resulting in the following error: error: bug in the test script: 'git diff-tree initial # magic is (not' does not look like a prereq Fix this by removing the redundant quotes. There's no need for them, and the resulting code works under all the aforementioned shells. This fixes a regression in c2f1d3989 ("t4013: test new output from diff --abbrev --raw", 2017-12-03) first released with Git v2.16.0. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-27t/helper: merge test-chmtime into test-toolLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-27diff: add --compact-summaryLibravatar Nguyễn Thái Ngọc Duy1-0/+5
Certain information is currently shown with --summary, but when used in combination with --stat it's a bit hard to read since info of the same file is in two places (--stat and --summary). On top of that, commits that add or remove files double the number of display lines, which could be a lot if you add or remove a lot of files. --compact-summary embeds most of --summary back in --stat in the little space between the file name part and the graph line, e.g. with commit 0433d533f1: Documentation/merge-config.txt | 4 + builtin/merge.c | 2 + ...-pull-verify-signatures.sh (new +x) | 81 ++++++++++++++ t/t7612-merge-verify-signatures.sh | 45 ++++++++ 4 files changed, 132 insertions(+) It helps both condensing information and saving some text space. What's new in diffstat is: - A new 0644 file is shown as (new) - A new 0755 file is shown as (new +x) - A new symlink is shown as (new +l) - A deleted file is shown as (gone) - A mode change adding executable bit is shown as (mode +x) - A mode change removing it is shown as (mode -x) Note that --compact-summary does not contain all the information --summary provides. Rewrite percentage is not shown but it could be added later, like R50% or C20%. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06t4013: test new output from diff --abbrev --rawLibravatar Ann T Ropea1-1/+15
Use newly-introduced finely-grained control to teach the diff-family to honor the new environment GIT_PRINT_SHA1_ELLIPSIS and remove the ellipses when it is not set. Mentored-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06t4013: prepare for upcoming "diff --raw --abbrev" output format changeLibravatar Ann T Ropea1-6/+23
Most of the t4013 tests go through a list of sample command lines, and each of them is executed and its output compared with an expected one stored in t4013/ directory. Allow these lines to begin with a colon followed by magic word(s) so that test conditions can easily be tweaked. The expected use that will happen in later steps of this is to run tests expecting the traditional output and run the same test without the GIT_PRINT_SHA1_ELLIPSIS=yes environment exported for (perhaps some of) them, which will have to expect different output. Since all of the existing tests are meant to run with the environment, use the magic word "noellipses" to cause the variable not to be set and exported. As this step does not add any new test with the magic word, all tests still run with the environment variable, expecting the traditional output, but it will change soon. Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-04print_sha1_ellipsis: introduce helperLibravatar Ann T Ropea1-1/+1
Introduce a helper print_sha1_ellipsis() that pays attention to the GIT_PRINT_SHA1_ELLIPSIS environment variable, and prepare the tests to unconditionally set it for the test pieces that will be broken once the code stops showing the extra dots by default. The removal of these dots is merely a plan at this step and has not happened yet but soon will. Document GIT_PRINT_SHA1_ELLIPSIS. Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-28diff: correct newline in summary for renamed filesLibravatar Stefan Beller1-0/+12
In 146fdb0dfe (diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY, 2017-06-29), the conversion from direct printing to the symbol emission dropped the new line character for renamed, copied and rewritten files. Add the emission of a newline, add a test for this case. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-08diff: handle --no-abbrev in no-index caseLibravatar Jack Bates1-0/+7
There are two different places where the --no-abbrev option is parsed, and two different places where SHA-1s are abbreviated. We normally parse --no-abbrev with setup_revisions(), but in the no-index case, "git diff" calls diff_opt_parse() directly, and diff_opt_parse() didn't handle --no-abbrev until now. (It did handle --abbrev, however.) We normally abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff: handle sha1 abbreviations outside of repository, 2016-10-20) recently introduced a special case when you run "git diff" outside of a repository. setup_revisions() does also call diff_opt_parse(), but not for --abbrev or --no-abbrev, which it handles itself. setup_revisions() sets rev_info->abbrev, and later copies that to diff_options->abbrev. It handles --no-abbrev by setting abbrev to zero. (This change doesn't touch that.) Setting abbrev to zero was broken in the outside-of-a-repository special case, which until now resulted in a truly zero-length SHA-1, rather than taking zero to mean do not abbreviate. The only way to trigger this bug, however, was by running "git diff --raw" without either the --abbrev or --no-abbrev options, because 1) without --raw it doesn't respect abbrev (which is bizarre, but has been that way forever), 2) we silently clamp --abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until now. The outside-of-a-repository case is one of three no-index cases. The other two are when one of the files you're comparing is outside of the repository you're in, and the --no-index option. Signed-off-by: Jack Bates <jack@nottheoilrig.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31graph: add support for --line-prefix on all graph-aware outputLibravatar Jacob Keller1-0/+6
Add an extension to git-diff and git-log (and any other graph-aware displayable output) such that "--line-prefix=<string>" will print the additional line-prefix on every line of output. To make this work, we have to fix a few bugs in the graph API that force graph_show_commit_msg to be used only when you have a valid graph. Additionally, we extend the default_diff_output_prefix handler to work even when no graph is enabled. This is somewhat of a hack on top of the graph API, but I think it should be acceptable here. This will be used by a future extension of submodule display which displays the submodule diff as the actual diff between the pre and post commit in the submodule project. Add some tests for both git-log and git-diff to ensure that the prefix is honored correctly. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25diff: activate diff.renames by defaultLibravatar Matthieu Moy1-0/+2
Rename detection is a very convenient feature, and new users shouldn't have to dig in the documentation to benefit from it. Potential objections to activating rename detection are that it sometimes fail, and it is sometimes slow. But rename detection is already activated by default in several cases like "git status" and "git merge", so activating diff.renames does not fundamentally change the situation. When the rename detection fails, it now fails consistently between "git diff" and "git status". This setting does not affect plumbing commands, hence well-written scripts will not be affected. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-28Merge branch 'maint'Libravatar Junio C Hamano1-0/+10
* maint: t4013: test diff-tree's --stdin commit formatting diff-tree: avoid lookup_unknown_object object_as_type: set commit index alloc: factor out commit index add object_as_type helper for casting objects parse_object_buffer: do not set object type move setting of object->type to alloc_* functions alloc: write out allocator definitions alloc.c: remove the alloc_raw_commit_node() function
2014-07-28t4013: test diff-tree's --stdin commit formattingLibravatar Jeff King1-0/+10
Once upon a time, git-log was just "rev-list | diff-tree", and we did not bother to test it separately. These days git-log is implemented internally, but we want to make sure that the rev-list to diff-tree pipeline continues to function. Let's add a basic sanity test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-30t4013-diff-various.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-3/+3
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 sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13diffstat summary line varies by locale: miscellanyLibravatar Jonathan Nieder1-1/+6
These changes are in the same spirit as the six patches that precede them, but they haven't been split into individually justifiable patches yet. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11Teach --dirstat not to completely ignore rearranged lines within a fileLibravatar Johan Herland1-2/+0
Currently, the --dirstat analysis ignores when lines within a file are rearranged, because the "damage" calculated by show_dirstat() is 0. However, if the object name has changed, we already know that there is some damage, and it is unintuitive to claim there is _no_ damage. Teach show_dirstat() to assign a minimum amount of damage (== 1) to entries for which the analysis otherwise yields zero damage, to still represent that these files are changed, instead of saying that there is no change. Also, skip --dirstat analysis when the object names are the same (e.g. for a pure file rename). Signed-off-by: Johan Herland <johan@herland.net> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11--dirstat-by-file: Make it faster and more correctLibravatar Johan Herland1-0/+2
Currently, when using --dirstat-by-file, it first does the full --dirstat analysis (using diffcore_count_changes()), and then resets 'damage' to 1, if any damage was found by diffcore_count_changes(). But --dirstat-by-file is not interested in the file damage per se. It only cares if the file changed at all. In that sense it only cares if the blob object for a file has changed. We therefore only need to compare the object names of each file pair in the diff queue and we can skip the entire --dirstat analysis and simply set 'damage' to 1 for each entry where the object name has changed. This makes --dirstat-by-file faster, and also bypasses --dirstat's practice of ignoring rearranged lines within a file. The patch also contains an added testcase verifying that --dirstat-by-file now detects changes that only rearrange lines within a file. Signed-off-by: Johan Herland <johan@herland.net> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11--dirstat: Describe non-obvious differences relative to --stat or regular diffLibravatar Johan Herland1-6/+21
Also add a testcase documenting the current behavior. Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09log: fix --max-count when used together with -S or -GLibravatar Matthieu Moy1-0/+3
The --max-count limit is implemented by counting revisions in get_revision(), but the -S and -G take effect later when running diff. Hence "--max-count=10 -Sfoo" meant "examine the 10 first revisions, and out of them, show only those changing the occurences of foo", not "show 10 revisions changing the occurences of foo". In case the commit isn't actually shown, cancel the decrement of max_count. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-07diff: support --cached on unborn branchesLibravatar Nguyễn Thái Ngọc Duy1-0/+11
"git diff --cached" (without revision) used to mean "git diff --cached HEAD" (i.e. the user was too lazy to type HEAD). This "correctly" failed when there was no commit yet. But was that correctness useful? This patch changes the definition of what particular command means. It is a request to show what _would_ be committed without further "git add". The internal implementation is the same "git diff --cached HEAD" when HEAD exists, but when there is no commit yet, it compares the index with an empty tree object to achieve the desired result. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-31diff/log -G<pattern>: testsLibravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06diff: parse separate options like -S fooLibravatar Matthieu Moy1-0/+5
Change the option parsing logic in revision.c to accept separate forms like `-S foo' in addition to `-Sfoo'. The rest of git already accepted this form, but revision.c still used its own option parsing. Short options affected are -S<string>, -l<num> and -O<orderfile>, for which an empty string wouldn't make sense, hence -<option> <arg> isn't ambiguous. This patch does not handle --stat-name-width and --stat-width, which are special-cases where diff_long_opt do not apply. They are handled in a separate patch to ease review. Original patch by Matthieu Moy, plus refactoring by Jonathan Nieder. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09show --first-parent/-m: do not default to --ccLibravatar Junio C Hamano1-0/+2
Given that "git show" always shows some diff and does not walk the history by default, it is natural to expect "git show --first-parent" to show the difference between the given commit and its first parent. It also would be natural, given that "--cc" is the default, "git show -m" to show pairwise difference from each of the parents. We however always defaulted to --cc and there was no way to turn it off. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09show -c: show patch textLibravatar Junio C Hamano1-0/+1
Traditionally, "show" defaulted to "show --cc" (dense combined patch), but asking for combined patch with "show -c" didn't turn the patch output format on; the placement of this logic in setup_revisions() dates back to cd2bdc5 (Common option parsing for "git log --diff" and friends, 2006-04-14). This unfortunately cannot be done as a trivial change of "if dense combined is asked, default to patch format" done in setup_revisions() to "if any combined is asked, default to patch format", as "diff-tree -c" needs to default to raw, while "diff-tree --cc" needs to default to patch, and they share the codepath. These command specific defaults are now handled in the new "tweak" callback that can be customized by individual command implementations. Signed-off-by: Junio C Hamano <gitster@pobox.com>