summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
11 daysMerge branch 'jc/fmt-merge-msg-suppress-destination' into masterJunio C Hamano
"git merge" learned to selectively omit " into <branch>" at the end of the title of default merge message with merge.suppressDest configuration. * jc/fmt-merge-msg-suppress-destination: fmt-merge-msg: allow merge destination to be omitted again Revert "fmt-merge-msg: stop treating `master` specially"
12 daysworktree: retire special-case normalization of main worktree pathEric Sunshine
In order for "git-worktree list" to present consistent results, get_main_worktree() performs manual normalization on the repository path (returned by get_common_dir()) after passing it through strbuf_add_absolute_path(). In particular, it cleans up the path for three distinct cases when the current working directory is (1) the main worktree, (2) the .git/ subdirectory, or (3) a bare repository. The need for such special-cases is a direct consequence of employing strbuf_add_absolute_path() which, for the sake of efficiency, doesn't bother normalizing the path (such as folding out redundant path components) after making it absolute. Lack of normalization is not typically a problem since redundant path elements make no difference when working with paths at the filesystem level. However, when preparing paths for presentation, possible redundant path components make it difficult to ensure consistency. Eliminate the need for these special cases by instead making the path absolute via strbuf_add_real_path() which normalizes the path for us. Once normalized, the only case we need to handle manually is converting it to the path of the main worktree by stripping the "/.git" suffix. This stripping of the "/.git" suffix is a regular idiom in worktree-related code; for instance, it is employed by get_linked_worktree(), as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysworktree: drop bogus and unnecessary path mungingEric Sunshine
The content of .git/worktrees/<id>/gitdir must be a path of the form "/path/to/worktree/.git". Any other content would be indicative of a corrupt "gitdir" file. To determine the path of the worktree itself one merely strips the "/.git" suffix, and this is indeed how the worktree path was determined from inception. However, 5193490442 (worktree: add a function to get worktree details, 2015-10-08) extended the path manipulation in a mysterious way. If it is unable to strip "/.git" from the path, then it instead reports the current working directory as the linked worktree's path: if (!strbuf_strip_suffix(&worktree_path, "/.git")) { strbuf_reset(&worktree_path); strbuf_add_absolute_path(&worktree_path, "."); strbuf_strip_suffix(&worktree_path, "/."); } This logic is clearly bogus; it can never be generally correct behavior. It materialized out of thin air in 5193490442 with neither explanation nor tests to illustrate a case in which it would be desirable. It's possible that this logic was introduced to somehow deal with a corrupt "gitdir" file, so that it returns _some_ sort of meaningful value, but returning the current working directory is not helpful. In fact, it is quite misleading (except in the one specific case when the current directory is the worktree whose "gitdir" entry is corrupt). Moreover, reporting the corrupt value to the user, rather than fibbing about it and hiding it outright, is more helpful since it may aid in diagnosing the problem. Therefore, drop this bogus path munging and restore the logic to the original behavior of merely stripping "/.git". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysworktree: drop unused code from get_linked_worktree()Eric Sunshine
This code has been unused since fa099d2322 (worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe(), 2017-04-24), so drop it. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysworktree: drop pointless strbuf_release()Eric Sunshine
The content of this strbuf is unconditionally detached several lines before the strbuf_release() and the strbuf is never touched again after that point. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 dayst6300: fix issues related to %(contents:size)Alban Gruin
b6839fda68 (ref-filter: add support for %(contents:size), 2020-07-16) added a new format for ref-filter, and added a function to generate tests for this new feature in t6300. Unfortunately, it tries to run `test_expect_sucess' instead of `test_expect_success', and writes $expect to `expected', but tries to read `expect'. Those two issues were probably unnoticed because the script only printed errors, but did not crash. This fixes these issues. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysrefs: move the logic to add \t to reflog to the files backendHan-Wen Nienhuys
523fa69c (reflog: cleanse messages in the refs.c layer, 2020-07-10) centralized reflog normalizaton. However, the normalizaton added a leading "\t" to the message. This is an artifact of the reflog storage format in the files backend, so it should be added there. Routines that parse back the reflog (such as grab_nth_branch_switch) expect the "\t" to not be in the message, so without this fix, git with reftable cannot process the "@{-1}" syntax. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysThe second batch -- mostly minor typofixesJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysMerge branch 'jb/doc-packfile-name' into masterJunio C Hamano
Doc update. * jb/doc-packfile-name: pack-write/docs: update regarding pack naming
12 daysMerge branch 'sg/ci-git-path-fix-with-pyenv' into masterJunio C Hamano
CI fixup---tests of Python scripts didn't use the version of Git that is being tested. * sg/ci-git-path-fix-with-pyenv: ci: use absolute PYTHON_PATH in the Linux jobs
12 daysMerge branch 'en/typofixes' into masterJunio C Hamano
* en/typofixes: hashmap: fix typo in usage docs Remove doubled words in various comments
12 daysMerge branch 'rs/grep-simpler-parse-object-or-die-call' into masterJunio C Hamano
* rs/grep-simpler-parse-object-or-die-call: grep: avoid using oid_to_hex() with parse_object_or_die()
12 daysMerge branch 'ar/help-guides-doc' into masterJunio C Hamano
* ar/help-guides-doc: git-help.txt: fix mentions of option --guides
12 daysMerge branch 'sk/typofixes' into masterJunio C Hamano
* sk/typofixes: comment: fix spelling mistakes inside comments
13 daysstrvec: rename struct fieldsJeff King
The "argc" and "argv" names made sense when the struct was argv_array, but now they're just confusing. Let's rename them to "nr" (which we use for counts elsewhere) and "v" (which is rather terse, but reads well when combined with typical variable names like "args.v"). Note that we have to update all of the callers immediately. Playing tricks with the preprocessor is hard here, because we wouldn't want to rewrite unrelated tokens. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 daysFirst batch post 2.28Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 daysMerge branch 'en/fill-directory-exponential' into masterJunio C Hamano
Fix to a regression introduced during 2.27 cycle. * en/fill-directory-exponential: dir: check pathspecs before returning `path_excluded`
13 daysMerge branch 'ct/mv-unmerged-path-error' into masterJunio C Hamano
"git mv src dst", when src is an unmerged path, errored out correctly but with an incorrect error message to claim that src is not tracked, which has been clarified. * ct/mv-unmerged-path-error: git-mv: improve error message for conflicted file
13 daysMerge branch 'bc/push-cas-cquoted-refname' into masterJunio C Hamano
Pushing a ref whose name contains non-ASCII character with the "--force-with-lease" option did not work over smart HTTP protocol, which has been corrected. * bc/push-cas-cquoted-refname: remote-curl: make --force-with-lease work with non-ASCII ref names
13 daysMerge branch 'cc/pretty-contents-size' into masterJunio C Hamano
"git for-each-ref --format=<>" learned %(contents:size). * cc/pretty-contents-size: ref-filter: add support for %(contents:size) t6300: test refs pointing to tree and blob Documentation: clarify %(contents:XXXX) doc
13 daysMerge branch 'rs/add-index-entry-optim-fix' into masterJunio C Hamano
Fix to an ancient bug caused by an over-eager attempt for optimization. * rs/add-index-entry-optim-fix: read-cache: remove bogus shortcut
13 daysMerge branch 'jt/avoid-lazy-fetching-upon-have-check' into masterJunio C Hamano
Fetching from a lazily cloned repository resulted at the server side in attempts to lazy fetch objects that the client side has, many of which will not be available from the third-party anyway. * jt/avoid-lazy-fetching-upon-have-check: upload-pack: do not lazy-fetch "have" objects
13 daysMerge branch 'dl/test-must-fail-fixes-6' into masterJunio C Hamano
Dev support to limit the use of test_must_fail to only git commands. * dl/test-must-fail-fixes-6: test-lib-functions: restrict test_must_fail usage t9400: don't use test_must_fail with cvs t9834: remove use of `test_might_fail p4` t7107: don't use test_must_fail() t5324: reorder `run_with_limited_open_files test_might_fail` t3701: stop using `env` in force_color()
13 daysMerge branch 'jk/reject-newer-extensions-in-v0' into masterJunio C Hamano
With the base fix to 2.27 regresion, any new extensions in a v0 repository would still be silently honored, which is not quite right. Instead, complain and die loudly. * jk/reject-newer-extensions-in-v0: verify_repository_format(): complain about new extensions in v0 repo
13 daysMerge branch 'hn/reftable' into masterJunio C Hamano
Preliminary clean-up of the refs API in preparation for adding a new refs backend "reftable". * hn/reftable: reflog: cleanse messages in the refs.c layer bisect: treat BISECT_HEAD as a pseudo ref t3432: use git-reflog to inspect the reflog for HEAD lib-t6000.sh: write tag using git-update-ref
13 daysMerge branch 'bw/fail-cloning-into-non-empty' into masterJunio C Hamano
"git clone --separate-git-dir=$elsewhere" used to stomp on the contents of the existing directory $elsewhere, which has been taught to fail when $elsewhere is not an empty directory. * bw/fail-cloning-into-non-empty: git clone: don't clone into non-empty directory
13 daysMerge branch 'pb/log-rev-list-doc' into masterJunio C Hamano
"git help log" has been enhanced by sharing more material from the documentation for the underlying "git rev-list" command. * pb/log-rev-list-doc: git-log.txt: include rev-list-description.txt git-rev-list.txt: move description to separate file git-rev-list.txt: tweak wording in set operations git-rev-list.txt: fix Asciidoc syntax revisions.txt: describe 'rev1 rev2 ...' meaning for ranges git-log.txt: add links to 'rev-list' and 'diff' docs
13 daysMerge branch 'jk/tests-timestamp-fix' into masterJunio C Hamano
The test framework has been updated so that most tests will run with predictable (artificial) timestamps. * jk/tests-timestamp-fix: t9100: stop depending on commit timestamps test-lib: set deterministic default author/committer date t9100: explicitly unset GIT_COMMITTER_DATE t5539: make timestamp requirements more explicit t9700: loosen ident timezone regex t6000: use test_tick consistently
13 daysMerge branch 'ds/commit-graph-bloom-updates' into masterJunio C Hamano
Updates to the changed-paths bloom filter. * ds/commit-graph-bloom-updates: commit-graph: check all leading directories in changed path Bloom filters revision: empty pathspecs should not use Bloom filters revision.c: fix whitespace commit-graph: check chunk sizes after writing commit-graph: simplify chunk writes into loop commit-graph: unify the signatures of all write_graph_chunk_*() functions commit-graph: persist existence of changed-paths bloom: fix logic in get_bloom_filter() commit-graph: change test to die on parse, not load commit-graph: place bloom_settings in context
13 daysMerge branch 'sg/commit-graph-cleanups' into masterJunio C Hamano
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'
13 daysfmt-merge-msg: allow merge destination to be omitted againJunio C Hamano
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>
13 daysRevert "fmt-merge-msg: stop treating `master` specially"Junio C Hamano
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>
13 dayst: remove test_oid_init in testsbrian m. carlson
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>
13 daysdocs: add documentation for extensions.objectFormatbrian m. carlson
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>
13 daysci: run tests with SHA-256brian m. carlson
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>
13 dayst: make SHA1 prerequisite depend on default hashbrian m. carlson
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>
13 dayst: allow testing different hash algorithms via environmentbrian m. carlson
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>
13 dayst: add test_oid option to select hash algorithmbrian m. carlson
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>
13 daysrepository: enable SHA-256 support by defaultbrian m. carlson
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>
13 dayssetup: add support for reading extensions.objectformatbrian m. carlson
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>
13 daysbundle: add new version for use with SHA-256brian m. carlson
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>
13 daysbuiltin/verify-pack: implement an --object-format optionbrian m. carlson
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>
13 dayshttp-fetch: set up git directory before parsing pack hashesbrian m. carlson
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>
13 dayst0410: mark test with SHA1 prerequisitebrian m. carlson
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>
13 dayst5308: make test work with SHA-256brian m. carlson
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>
13 dayst9700: make hash size independentbrian m. carlson
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>
13 dayst9500: ensure that algorithm info is preserved in configbrian m. carlson
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>
13 dayst9350: make hash size independentbrian m. carlson
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>
13 dayst9301: make hash size independentbrian m. carlson
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>
13 dayst9300: use $ZERO_OID instead of hard-coded object IDbrian m. carlson
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>