git/Documentation/gitdiffcore.txt, branch v2.31.2

Merge branch 'en/diffcore-rename'

2021-03-01T22:02:56Z

Performance optimization work on the rename detection continues. * en/diffcore-rename: merge-ort: call diffcore_rename() directly gitdiffcore doc: mention new preliminary step for rename detection diffcore-rename: guide inexact rename detection based on basenames diffcore-rename: complete find_basename_matches() diffcore-rename: compute basenames of source and dest candidates t4001: add a test comparing basename similarity and content similarity diffcore-rename: filter rename_src list when possible diffcore-rename: no point trying to find a match better than exact

diff: --{rotate,skip}-to=

2021-02-16T17:30:42Z

In the implementation of "git difftool", there is a case where the user wants to start viewing the diffs at a specific path and continue on to the rest, optionally wrapping around to the beginning. Since it is somewhat cumbersome to implement such a feature as a post-processing step of "git diff" output, let's support it internally with two new options. - "git diff --rotate-to=C", when the resulting patch would show paths A B C D E without the option, would "rotate" the paths to shows patch to C D E A B instead. It is an error when there is no patch for C is shown. - "git diff --skip-to=C" would instead "skip" the paths before C, and shows patch to C D E. Again, it is an error when there is no patch for C is shown. - "git log [-p]" also accepts these two options, but it is not an error if there is no change to the specified path. Instead, the set of output paths are rotated or skipped to the specified path or the first path that sorts after the specified path. Signed-off-by: Junio C Hamano

gitdiffcore doc: mention new preliminary step for rename detection

2021-02-16T02:02:16Z

The last few patches have introduced a new preliminary step when rename detection is on but both break detection and copy detection are off. Document this new step. While we're at it, add a testcase that checks the new behavior as well. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

log -G: ignore binary files

2018-12-26T22:59:37Z

The -G option of log looks for the differences whose patch text contains added/removed lines that match regex. Currently -G looks also into patches of binary files (which according to [1]) is binary as well. This has a couple of issues: - It makes the pickaxe search slow. In a proprietary repository of the author with only ~5500 commits and a total .git size of ~300MB searching takes ~13 seconds $time git log -Gwave > /dev/null real 0m13,241s user 0m12,596s sys 0m0,644s whereas when we ignore binary files with this patch it takes ~4s $time ~/devel/git/git log -Gwave > /dev/null real 0m3,713s user 0m3,608s sys 0m0,105s which is a speedup of more than fourfold. - The internally used algorithm for generating patch text is based on xdiff and its states in [1] > The output format of the binary patch file is proprietary > (and binary) and it is basically a collection of copy and insert > commands [..] which means that the current format could change once the internal algorithm is changed as the format is not standardized. In addition the git binary patch format used for preparing patches for git apply is *different* from the xdiff format as can be seen by comparing git log -p -a commit 6e95bf4bafccf14650d02ab57f3affe669be10cf Author: A U Thor Date: Thu Apr 7 15:14:13 2005 -0700 modify binary file diff --git a/data.bin b/data.bin index f414c84..edfeb6f 100644 --- a/data.bin +++ b/data.bin @@ -1,2 +1,4 @@ a a^@a +a +a^@a with git log --binary commit 6e95bf4bafccf14650d02ab57f3affe669be10cf Author: A U Thor Date: Thu Apr 7 15:14:13 2005 -0700 modify binary file diff --git a/data.bin b/data.bin index f414c84bd3aa25fa07836bb1fb73db784635e24b..edfeb6f501[..] GIT binary patch literal 12 QcmYe~N@Pgn0zx1O01)N^ZvX%Q literal 6 NcmYe~N@Pgn0ssWg0XP5v which seems unexpected. To resolve these issues this patch makes -G ignore binary files by default. Textconv filters are supported and also -a/--text for getting the old and broken behaviour back. The -S option of log looks for differences that changes the number of occurrences of the specified block of text (i.e. addition/deletion) in a file. As we want to keep the current behaviour, add a test to ensure it stays that way. [1]: http://www.xmailserver.org/xdiff.html Signed-off-by: Thomas Braun Signed-off-by: Junio C Hamano

docs/diffcore: unquote "Complete Rewrites" in headers

2017-02-28T19:34:38Z

The gitdiffcore documentation quotes the term "Complete Rewrites" in headers for no real gain. This would make sense if the term could be easily confused if not properly grouped together. But actually, the term is quite obvious and thus does not really need any quoting, especially regarding that it is not used anywhere else. But more importanly, this brings up a bug when rendering man pages: when trying to render quotes inside of a section header, we end up with quotes which have been misaligned to the end of line. E.g. diffcore-break: For Splitting Up Complete Rewrites -------------------------------------------------- renders as DIFFCORE-BREAK: FOR SPLITTING UP COMPLETE REWRITES"" , which is obviously wrong. While this is fixable for the man pages by using double-quotes (e.g. ""COMPLETE REWRITES""), this again breaks it for our generated HTML pages. So fix the issue by simply dropping quotes inside of section headers, which is currently only done for the term "Complete Rewrites". Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

docs/diffcore: fix grammar in diffcore-rename header

2017-02-28T19:34:36Z

Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'sb/doc-unify-bottom'

2017-02-15T20:54:20Z

Doc clean-up. * sb/doc-unify-bottom: Documentation: unify bottom "part of git suite" lines

Documentation: unify bottom "part of git suite" lines

2017-02-09T23:14:01Z

We currently have 168 man pages that mention they are part of Git, you can check yourself easily via: $ git grep "Part of the linkgit:git\[1\] suite" |wc -l 168 However some have a trailing period, i.e. $ git grep "Part of the linkgit:git\[1\] suite." |wc -l 8 Unify the bottom line in all man pages to not end with a period. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

doc: typeset long command-line options as literal

2016-06-28T15:36:45Z

Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

doc: convert \--option to --option

2015-05-13T05:14:46Z

Older versions of AsciiDoc would convert the "--" in "--option" into an emdash. According to 565e135 (Documentation: quote double-dash for AsciiDoc, 2011-06-29), this is fixed in AsciiDoc 8.3.0. According to bf17126, we don't support anything older than 8.4.1 anyway, so we no longer need to worry about quoting. Even though this does not change the output at all, there are a few good reasons to drop the quoting: 1. It makes the source prettier to read. 2. We don't quote consistently, which may be confusing when reading the source. 3. Asciidoctor does not like the quoting, and renders a literal backslash. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano