summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-30Merge branch 'sg/commit-graph-cleanups' into masterJunio C Hamano13-108/+117
The changed-path Bloom filter is improved using ideas from an independent implementation. * sg/commit-graph-cleanups: commit-graph: simplify write_commit_graph_file() #2 commit-graph: simplify write_commit_graph_file() #1 commit-graph: simplify parse_commit_graph() #2 commit-graph: simplify parse_commit_graph() #1 commit-graph: clean up #includes diff.h: drop diff_tree_oid() & friends' return value commit-slab: add a function to deep free entries on the slab commit-graph-format.txt: all multi-byte numbers are in network byte order commit-graph: fix parsing the Chunk Lookup table tree-walk.c: don't match submodule entries for 'submod/anything'
2020-07-30fmt-merge-msg: allow merge destination to be omitted againJunio C Hamano3-4/+66
In Git 2.28, we stopped special casing 'master' when producing the default merge message by just removing the code to squelch "into 'master'" at the end of the message. Introduce multi-valued merge.suppressDest configuration variable that gives a set of globs to match against the name of the branch into which the merge is being made, to let users specify for which branch fmt-merge-msg's output should be shortened. When it is not set, 'master' is used as the sole value of the variable by default. The above move mostly reverts the pre-2.28 default in repositories that have no relevant configuration. Add a few tests to protect the behaviour with the new configuration variable from future regression. Helped-by: Linus Torvalds <torvalds@linux-foundation.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Revert "fmt-merge-msg: stop treating `master` specially"Junio C Hamano29-94/+97
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-30t: remove test_oid_init in testsbrian m. carlson28-37/+2
Now that we call test_oid_init in the setup for all test scripts, there's no point in calling it individually. Remove all of the places where we've done so to help keep tests tidy. 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-07-30docs: add documentation for extensions.objectFormatbrian m. carlson2-0/+10
Document the extensions.objectFormat config setting. Warn users not to modify it themselves. 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-07-30ci: run tests with SHA-256brian m. carlson1-0/+6
Now that we have Git supporting SHA-256, we'd like to make sure that we don't regress that state. Unfortunately, it's easy to do so, so to help, let's add code to run one of our CI jobs with SHA-256 as the default hash. This will help us detect any problems that may occur. We pick the linux-clang job because it's relatively fast and the linux-gcc job already runs the testsuite twice. We want our tests to run as fast as possible, so we wouldn't want to add a third run to the linux-gcc job. To make sure we properly exercise the code, let's run the tests in the default mode (SHA-1) first and then run a second time with SHA-256. We explicitly specify SHA-1 for the first run so that if we change the default in the future, we make sure to test both cases. 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-07-30t: make SHA1 prerequisite depend on default hashbrian m. carlson1-1/+5
Currently, the SHA1 prerequisite depends on the output of git hash-object. However, in order for that to produce sane behavior, we must be in a repository. If we are not, the default will remain SHA-1, and we'll produce wrong results if we're using SHA-256 for the testsuite but the test assertion starts when we're not in a repository. Check the environment variable we use for this purpose, leaving it to default to SHA-1 if none is specified. 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-07-30t: allow testing different hash algorithms via environmentbrian m. carlson2-3/+4
To allow developers to run the testsuite with a different algorithm than the default, provide an environment variable, GIT_TEST_DEFAULT_HASH, to specify the algorithm to use. Compute the fixed constants using test_oid. Move the constant initialization down below the point where test-lib-functions.sh is loaded so the functions are defined. 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-07-30t: add test_oid option to select hash algorithmbrian m. carlson2-1/+22
In some tests, we have data files which are written with a particular hash algorithm. Instead of keeping two copies of the test files, we can keep one, and translate the value on the fly. In order to do so, we'll need to read both the source algorithm and the current algorithm, so add an optional flag to the test_oid helper that lets us look up a value for a specified hash algorithm. This should not cause any conflicts with existing tests, since key arguments to test_oid are allowed to contains only shell identifier characters. 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-07-30repository: enable SHA-256 support by defaultbrian m. carlson4-11/+33
Now that we have a complete SHA-256 implementation in Git, let's enable it so people can use it. Remove the ENABLE_SHA256 define constant everywhere it's used. Add tests for initializing a repository with SHA-256. 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-07-30setup: add support for reading extensions.objectformatbrian m. carlson1-1/+15
The transition plan specifies extensions.objectFormat as the indication that we're using a given hash in a certain repo. Read this as one of the extensions we support. If the user has specified an invalid value, fail. Ensure that we reject the extension if the repository format version is 0. 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-07-30bundle: add new version for use with SHA-256brian m. carlson7-31/+147
Currently we detect the hash algorithm in use by the length of the object ID. This is inelegant and prevents us from using a different hash algorithm that is also 256 bits in length. Since we cannot extend the v2 format in a backward-compatible way, let's add a v3 format, which is identical, except for the addition of capabilities, which are prefixed by an at sign. We add "object-format" as the only capability and reject unknown capabilities, since we do not have a network connection and therefore cannot negotiate with the other side. For compatibility, default to the v2 format for SHA-1 and require v3 for SHA-256. In t5510, always use format v3 so we can be sure we produce consistent results across hash algorithms. Since head -n N lists the top N lines instead of the Nth line, let's run our output through sed to normalize it and compare it against a fixed value, which will make sure we get exactly what we're expecting. 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-07-30builtin/verify-pack: implement an --object-format optionbrian m. carlson2-9/+16
A recently added test in t5702 started using git verify-pack outside of a repository. While this poses no problems with SHA-1, with SHA-256 we implicitly rely on the setup of the repository to initialize our hash algorithm settings. Since we're not in a repository here, we need to provide git verify-pack help to set things up properly. git index-pack already knows an --object-format option, so let's accept one as well and pass it down to our git index-pack invocation. Since we're now dynamically adjusting the elements in argv, let's switch to using struct argv_array to manage them. Finally, let's make t5702 pass the proper argument on down to its git verify-pack caller. 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-07-30http-fetch: set up git directory before parsing pack hashesbrian m. carlson1-1/+5
In dd4b732df7 ("upload-pack: send part of packfile response as uri", 2020-06-10), the git http-fetch code learned how to take ac --packfile option. This option takes an argument, which is the name of a packfile hash, and parses it using parse_oid_hex. It does so before calling setup_git_directory. However, in a SHA-256 repository this fails to work, since we have not set the hash algorithm in use and parse_oid_hex fails as a consequence. To ensure that we can parse packfile hashes of the right length, let's set up the git directory before we start parsing arguments. Since we still want to allow the invocation of -h to print the help when we're not in a repository, gracefully handle us being outside of one and produce an error after argument parsing has finished. 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-07-30t0410: mark test with SHA1 prerequisitebrian m. carlson1-2/+2
These tests try to check that we behave properly if we encounter a repository with version 0 but an extension. This is a laudable goal, but the test cannot work with SHA-256, since SHA-256 repositories always have an existing extension and are never version 0. Add a SHA1 prerequisite to these tests. 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-07-30t5308: make test work with SHA-256brian m. carlson2-8/+20
This test needs multiple object IDs that have the same first byte. Update the pack test code to generate a suitable packed value for SHA-256. Update the test to use this value when using SHA-256. 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-07-30t9700: make hash size independentbrian m. carlson1-2/+4
The Perl test script for t9700 was matching on exactly 40 hex characters. With SHA-256, we'll have 64 hex-character object IDs. Create a variable with a regex which matches exactly 40 or 64 hex characters and use that to match the output. Note that both of the uses of this can be anchored, which makes the code simpler, so do that as well. 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-07-30t9500: ensure that algorithm info is preserved in configbrian m. carlson1-6/+16
When we use a hash algorithm other than SHA-1, it's important to preserve the hash-related values in the config file, but this test overwrites the config file with a new one. Ensure we copy these values properly from the old config to the new one so that the repository can be read if it's using SHA-256. Note that if there is no extensions.objectFormat value set, git config will return unsuccessfully if we try to read it; since this is not an error for us, use test_might_fail. 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-07-30t9350: make hash size independentbrian m. carlson1-7/+7
This test checks for several commit object sizes to verify that objects are encoded as expected. However, the size of a commit object differs between SHA-1 and SHA-256, since each contains a hex representation of the tree's object ID. Since these are root commits, compute the size of each commit by using a constant plus the size of a single hex object ID. In addition, use $ZERO_OID instead of a hard-coded object ID. 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-07-30t9301: make hash size independentbrian m. carlson1-6/+6
Instead of using a hard-coded all-zeros object ID, use $ZERO_OID. Compute the length of the object IDs in use and use this instead of hard-coding the constant 40. 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-07-30t9300: use $ZERO_OID instead of hard-coded object IDbrian m. carlson1-8/+8
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-07-30t9300: abstract away SHA-1-specific constantsbrian m. carlson1-49/+59
Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. In addition, use cut to filter out the object IDs and verify only the information that we're really interested in. 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-07-30t8011: make hash size independentbrian m. carlson1-1/+1
Allow lines which start with either a 40- or 64-character hex object ID, to allow for both SHA-1 and SHA-256. 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-07-30t8003: make hash size independentbrian 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-07-30t8002: make hash size independentbrian m. carlson1-7/+11
Compute the length of an object ID instead of hard-coding 40-based values. 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-07-30t7508: use $ZERO_OID instead of hard-coded constantbrian m. carlson1-1/+1
Use the ZERO_OID variable to abbreviate the all-zeros object ID for maintainability and to avoid depending on a specific size for the hash. 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-07-30t7506: avoid checking for SHA-1-specific constantsbrian m. carlson1-4/+8
Adjust the test to sanitize the diffs and strip out object IDs from them, as it does for other object IDs, since we are not interested in the particular values used. 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-07-30t7405: make hash size independentbrian m. carlson1-2/+2
Use $ZERO_OID instead of hard-coding a fixed size all-zeros object ID. 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-07-30t7400: make hash size independentbrian m. carlson1-13/+13
Instead of using cut with hard-coded hash sizes, use cut with fields, or where that's not possible, sed with $OID_REGEX, so that the tests are independent of hash size. 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-07-30t7102: abstract away SHA-1-specific constantsbrian m. carlson1-40/+53
Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. 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-07-30t7201: abstract away SHA-1-specific constantsbrian m. carlson1-2/+4
Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. 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-07-30t7063: make hash size independentbrian m. carlson1-70/+80
Use test_oid instead of hard-coding algorithm-specific constants and all-zero values. 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-07-30t7003: compute appropriate length constantbrian m. carlson1-1/+2
Instead of using a specific invalid hard-coded object ID, look one up from the translation table. 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-07-30t6501: avoid hard-coded objectsbrian m. carlson1-7/+7
This test contains hard-coded invalid object IDs. Make it hash size independent by generating invalid object IDs using the translation tables. Add a setup target to ensure the output of test_oid_init is checked properly. 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-07-30t6500: specify test values for SHA-256brian m. carlson1-5/+22
In this test, we want to produce several blobs whose first two hex characters are "17", since we look at this object directory as a proxy for how many loose objects there are before we need to GC. Use test_oid_cache to specify strings that will hash to the right values when turned into blobs. 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-07-30t6301: make hash size independentbrian m. carlson1-1/+1
Instead of hard-coding a fixed length example object ID in the test, compute one using the translation tables. Move a variable into the setup block so that we can ensure the exit status of test_oid is checked. 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-07-30t6101: make hash size independentbrian m. carlson1-1/+1
Use $OID_REGEX instead of a hard-coded regular expression. 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-07-30t6100: make hash size independentbrian m. carlson1-2/+2
Instead of hard-coding a constant 40, split the output of rev-list by field. 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-07-30t3404: prepare 'short SHA-1 collision' tests for SHA-256Johannes Schindelin1-9/+40
The idea of the magic value "ac4f2ee" in this test is to make the reworded commit `collide2` have the same shortened ID as the commit `collide3`. To port the same idea to the SHA-256 version of Git, we therefore need another magic value that causes the same collision, but this time with the SHA-256 version of the commit IDs. In this patch, we add code guarded by `GIT_TEST_FIND_COLLIDER` to do exactly that. Essentially, a large number of integers is appended to the commit message "collide2" to find such a collision. To make it easier to find such a collision, we reduce the number of digits to 4. As the tests are no longer dependent on SHA-1, we also rename their titles to talk about "commit IDs" instead of "SHA-1s". Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 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-07-30t3305: make hash agnosticbrian m. carlson1-1/+1
When computing the fanout length, let's use test_oid to look up the hexadecimal size of the hash in question instead of hard-coding a value. 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-07-30t1001: use $ZERO_OIDbrian m. carlson1-2/+2
Use $ZERO_OID to make the test hash independent. 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-07-30t: make test-bloom initialize repositorybrian m. carlson1-0/+2
The bloom filter code relies on reading object IDs using parse_oid_hex. In order to make that work with an appropriate size, we need to have initialized the repository's hash algorithm. Since the values we're processing depend on the repository in use, let's set up the repository when we run the test helper. 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-07-29mergetools: add support for nvimdiff (neovim) familypudinha4-10/+17
Signed-off-by: pudinha <rogi@skylittlesystem.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29mergetool--lib: improve support for vimdiff-style tool variantspudinha8-10/+36
The merge tools vimdiff2, vimdiff3, gvimdiff2, gvimdiff3 and bc3 are all variants of the main tools vimdiff and bc. They are implemented in the main and a one-liner script that just sources it exist for each. Allow variants ending in [0-9] to be correctly wired without the need for such one-liners, so instead of 5 scripts, only 1 (gvimdiff) is needed. Signed-off-by: pudinha <rogi@skylittlesystem.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: clarify handling of merge commit diffsJeff King1-0/+7
It can be surprising that git-log doesn't show any diff for merge commits by default. Arguably "--cc" would be a reasonable default, but it's very expensive (which is why we turn it on for "git show" but not for "git log"). Let's at least document the current behavior, including the recent "--first-parent implies -m" case Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: move "-t" into diff-options listJeff King2-3/+5
The "-t" option is infrequently used; it doesn't deserve a spot near the top of the options list. Let's push it down into the diff-options include, near the definition of --raw. We'll protect it with a git-log ifdef, since it doesn't make any sense for non-tree diff commands. Note that this means it also shows up in git-show, but that's a good thing; it applies equally well there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: drop "-r" diff optionJeff King1-4/+1
This has been the default since 170c04383b (Porcelain level "log" family should recurse when diffing., 2007-08-27). There's not even a way to turn it off, so you'd never even want "-r" to override that. It's not the default for plumbing like diff-tree, of course, but the option is documented separately there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: move "Diff Formatting" from rev-list-optionsJeff King2-48/+40
Our rev-list-options.txt include has a "Diff Formatting" section, but it is ifndef'd out for all manpages except git-log. And a few bits of the text are rather out of date. We say "some of these options are specific to git-rev-list". That's obviously silly since we (even before this patch) show the content only for git-log. But moreover, it's not true; each of the listed options is meaningful for other diff commands. We also say "...however other diff options may be given. See git-diff-files for more options." But there's no need to do so; git-log already has a "Common Diff Options" section which includes diff-options.txt. So let's move these options over to git-log and put them with the other diff options, giving a single "diff" section for the git-log documentation. We'll call it "Diff Formatting" but use the all-caps top-level header to match its sibling sections. And we'll rewrite the section intro to remove the useless bits and give a more generic overview of the section which can be later extended. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29log: enable "-m" automatically with "--first-parent"Jeff King2-0/+25
When using "--first-parent" to consider history as a single line of commits, git-log still defaults to treating merges specially, even though they could be considered as single commits in the linearized history (that just introduce all of the changes from the second and higher parents). Let's instead have "--first-parent" imply "-m", which makes something like: git log --first-parent -p do what you'd expect. Likewise: git log --first-parent -Sfoo will find "foo" in merge commits. No new test is needed; we'll tweak the output of the existing "--first-parent -p" test, which now matches the "-m --first-parent -p" test. The unchanged existing test for "--no-diff-merges" confirms that the user can get the old behavior if they want. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29revision: add "--no-diff-merges" option to counteract "-m"Jeff King6-6/+90
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>