summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-07-06Merge branch 'dl/test-must-fail-fixes-5'Libravatar Junio C Hamano13-59/+121
The effort to avoid using test_must_fail on non-git command continues. * dl/test-must-fail-fixes-5: lib-submodule-update: pass 'test_must_fail' as an argument lib-submodule-update: prepend "git" to $command lib-submodule-update: consolidate --recurse-submodules lib-submodule-update: add space after function name
2020-07-06Merge branch 'jk/fast-export-anonym-alt'Libravatar Junio C Hamano1-16/+38
"git fast-export --anonymize" learned to take customized mapping to allow its users to tweak its output more usable for debugging. * jk/fast-export-anonym-alt: fast-export: use local array to store anonymized oid fast-export: anonymize "master" refname fast-export: allow seeding the anonymized mapping fast-export: add a "data" callback parameter to anonymize_str() fast-export: move global "idents" anonymize hashmap into function fast-export: use a flex array to store anonymized entries fast-export: stop storing lengths in anonymized hashmaps fast-export: tighten anonymize_mem() interface to handle only strings fast-export: store anonymized oids as hex strings fast-export: use xmemdupz() for anonymizing oids t9351: derive anonymized tree checks from original repo
2020-07-06Merge branch 'js/diff-files-i-t-a-fix-for-difftool'Libravatar Junio C Hamano2-3/+10
"git difftool" has trouble dealing with paths added to the index with the intent-to-add bit. * js/diff-files-i-t-a-fix-for-difftool: difftool -d: ensure that intent-to-add files are handled correctly diff-files --raw: show correct post-image of intent-to-add files
2020-07-06Merge branch 'js/default-branch-name'Libravatar Junio C Hamano34-95/+176
The name of the primary branch in existing repositories, and the default name used for the first branch in newly created repositories, is made configurable, so that we can eventually wean ourselves off of the hardcoded 'master'. * js/default-branch-name: contrib: subtree: adjust test to change in fmt-merge-msg testsvn: respect `init.defaultBranch` remote: use the configured default branch name when appropriate clone: use configured default branch name when appropriate init: allow setting the default for the initial branch name via the config init: allow specifying the initial branch name for the new repository docs: add missing diamond brackets submodule: fall back to remote's HEAD for missing remote.<name>.branch send-pack/transport-helper: avoid mentioning a particular branch fmt-merge-msg: stop treating `master` specially
2020-07-06Merge branch 'bc/http-push-flagsfix'Libravatar Junio C Hamano1-0/+16
The code to push changes over "dumb" HTTP had a bad interaction with the commit reachability code due to incorrect allocation of object flag bits, which has been corrected. * bc/http-push-flagsfix: http-push: ensure unforced pushes fail when data would be lost
2020-07-06Merge branch 'js/pu-to-seen'Libravatar Junio C Hamano3-14/+14
The documentation and some tests have been adjusted for the recent renaming of "pu" branch to "seen". * js/pu-to-seen: tests: reference `seen` wherever `pu` was referenced docs: adjust the technical overview for the rename `pu` -> `seen` docs: adjust for the recent rename of `pu` to `seen`
2020-07-06Merge branch 'cb/is-descendant-of'Libravatar Junio C Hamano1-1/+1
Code clean-up. * cb/is-descendant-of: commit-reach: avoid is_descendant_of() shim
2020-07-06Merge branch 'es/get-worktrees-unsort'Libravatar Junio C Hamano1-1/+1
API cleanup for get_worktrees() * es/get-worktrees-unsort: worktree: drop get_worktrees() unused 'flags' argument worktree: drop get_worktrees() special-purpose sorting option
2020-07-06Merge branch 'bc/sha-256-cvs-svn-updates'Libravatar Junio C Hamano7-25/+44
CVS/SVN interface have been prepared for SHA-256 transition * bc/sha-256-cvs-svn-updates: git-cvsexportcommit: port to SHA-256 git-cvsimport: port to SHA-256 git-cvsserver: port to SHA-256 git-svn: set the OID length based on hash algorithm perl: make SVN code hash independent perl: make Git::IndexInfo work with SHA-256 perl: create and switch variables for hash constants t/lib-git-svn: make hash size independent t9101: make hash independent t9104: make hash size independent t9100: make test work with SHA-256 t9108: make test hash independent t9168: make test hash independent t9109: make test hash independent
2020-07-06Merge branch 'ak/commit-graph-to-slab'Libravatar Junio C Hamano1-1/+1
A few fields in "struct commit" that do not have to always be present have been moved to commit slabs. * ak/commit-graph-to-slab: commit-graph: minimize commit_graph_data_slab access commit: move members graph_pos, generation to a slab commit-graph: introduce commit_graph_data_slab object: drop parsed_object_pool->commit_count
2020-07-06Merge branch 'ps/ref-transaction-hook'Libravatar Junio C Hamano2-0/+141
A new hook. * ps/ref-transaction-hook: refs: implement reference transaction hook
2020-07-06Merge branch 'bc/sha-256-part-2'Libravatar Junio C Hamano15-191/+274
SHA-256 migration work continues. * bc/sha-256-part-2: (44 commits) remote-testgit: adapt for object-format bundle: detect hash algorithm when reading refs t5300: pass --object-format to git index-pack t5704: send object-format capability with SHA-256 t5703: use object-format serve option t5702: offer an object-format capability in the test t/helper: initialize the repository for test-sha1-array remote-curl: avoid truncating refs with ls-remote t1050: pass algorithm to index-pack when outside repo builtin/index-pack: add option to specify hash algorithm remote-curl: detect algorithm for dumb HTTP by size builtin/ls-remote: initialize repository based on fetch t5500: make hash independent serve: advertise object-format capability for protocol v2 connect: parse v2 refs with correct hash algorithm connect: pass full packet reader when parsing v2 refs Documentation/technical: document object-format for protocol v2 t1302: expect repo format version 1 for SHA-256 builtin/show-index: provide options to determine hash algo t5302: modernize test formatting ...
2020-07-01difftool -d: ensure that intent-to-add files are handled correctlyLibravatar Johannes Schindelin1-0/+8
In https://github.com/git-for-windows/git/issues/2677, a `git difftool -d` problem was reported. The underlying cause was a bug in `git diff-files --raw` that we just fixed: it reported intent-to-add files with the empty _tree_ as the post-image OID, when we need to show an all-zero (or, "null") OID instead, to indicate to the caller that they have to look at the worktree file. The symptom of that problem shown by `git difftool` was this: error: unable to read sha1 file of <path> (<empty-tree-OID>) error: could not write '<filename>' Make sure that the reported `difftool` problem stays fixed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-01diff-files --raw: show correct post-image of intent-to-add filesLibravatar Johannes Schindelin1-3/+2
The documented behavior of `git diff-files --raw` is to display [...] 0{40} if creation, unmerged or "look at work tree". on the right hand (i.e. postimage) side. This happens for files that have unstaged modifications, and for files that are unmodified but stat-dirty. For intent-to-add files, we used to show the empty blob's hash instead. In c26022ea8f5 (diff: convert diff_addremove to struct object_id, 2017-05-30), we made that worse by inadvertently changing that to the hash of the empty tree. Let's make the behavior consistent with files that have unstaged modifications (which applies to intent-to-add files, too) by showing all-zero values also for intent-to-add files. Accordingly, this patch adjusts the expectations set by the regression test introduced in feea6946a5b (diff-files: treat "i-t-a" files as "not-in-index", 2020-06-20). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-29Merge branch 'sk/diff-files-show-i-t-a-as-new'Libravatar Junio C Hamano1-8/+45
"git diff-files" has been taught to say paths that are marked as intent-to-add are new files, not modified from an empty blob. * sk/diff-files-show-i-t-a-as-new: diff-files: treat "i-t-a" files as "not-in-index"
2020-06-29Merge branch 'xl/upgrade-repo-format'Libravatar Junio C Hamano5-4/+26
Allow runtime upgrade of the repository format version, which needs to be done carefully. There is a rather unpleasant backward compatibility worry with the last step of this series, but it is the right thing to do in the longer term. * xl/upgrade-repo-format: check_repository_format_gently(): refuse extensions for old repositories sparse-checkout: upgrade repository to version 1 when enabling extension fetch: allow adding a filter after initial clone repository: add a helper function to perform repository format upgrade
2020-06-25fast-export: anonymize "master" refnameLibravatar Jeff King1-5/+7
Running "fast-export --anonymize" will leave "refs/heads/master" untouched in the output, for two reasons: - it helped to have some known reference point between the original and anonymized repository - since it's historically the default branch name, it doesn't leak any information Now that we can ask fast-export to retain particular tokens, we have a much better tool for the first one (because it works for any ref, not just master). For the second, the notion of "default branch name" is likely to become configurable soon, at which point the name _does_ leak information. Let's drop this special case in preparation. Note that we have to adjust the test a bit, since it relied on using the name "master" in the anonymized repos. We could just use --anonymize-map=master to keep the same output, but then we wouldn't know if it works because of our hard-coded master or because of the explicit map. So let's flip the test a bit, and confirm that we anonymize "master", but keep "other" in the output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-25fast-export: allow seeding the anonymized mappingLibravatar Jeff King1-1/+10
After you anonymize a repository, it can be hard to find which commits correspond between the original and the result, and thus hard to reproduce commands that triggered bugs in the original. Let's make it possible to seed the anonymization map. This lets users either: - mark names to be retained as-is, if they don't consider them secret (in which case their original commands would just work) - map names to new values, which lets them adapt the reproduction recipe to the new names without revealing the originals The implementation is fairly straight-forward. We already store each anonymized token in a hashmap (so that the same token appearing twice is converted to the same result). We can just introduce a new "seed" hashmap which is consulted first. This does make a few more promises to the user about how we'll anonymize things (e.g., token-splitting pathnames). But it's unlikely that we'd want to change those rules, even if the actual anonymization of a single token changes. And it makes things much easier for the user, who can unblind only a directory name without having to specify each path within it. One alternative to this approach would be to anonymize as we see fit, and then dump the whole refname and pathname mappings to a file. This does work, but it's a bit awkward to use (you have to manually dig the items you care about out of the mapping). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-25Merge branch 'pb/t4014-unslave'Libravatar Junio C Hamano1-4/+4
A branch name used in a test has been clarified to match what is going on. * pb/t4014-unslave: t4014: do not use "slave branch" nomenclature
2020-06-25Merge branch 'jt/cdn-offload'Libravatar Junio C Hamano2-0/+118
The "fetch/clone" protocol has been updated to allow the server to instruct the clients to grab pre-packaged packfile(s) in addition to the packed object data coming over the wire. * jt/cdn-offload: upload-pack: fix a sparse '0 as NULL pointer' warning upload-pack: send part of packfile response as uri fetch-pack: support more than one pack lockfile upload-pack: refactor reading of pack-objects out Documentation: add Packfile URIs design doc Documentation: order protocol v2 sections http-fetch: support fetching packfiles by URL http-fetch: refactor into function http: refactor finish_http_pack_request() http: use --stdin when indexing dumb HTTP pack
2020-06-25Merge branch 'dl/branch-cleanup'Libravatar Junio C Hamano1-24/+43
Code clean-up around "git branch" with a minor bugfix. * dl/branch-cleanup: branch: don't mix --edit-description t3200: test for specific errors t3200: rename "expected" to "expect"
2020-06-25Merge branch 'ct/diff-with-merge-base-clarification'Libravatar Junio C Hamano2-1/+92
"git diff" used to take arguments in random and nonsense range notation, e.g. "git diff A..B C", "git diff A..B C...D", etc., which has been cleaned up. * ct/diff-with-merge-base-clarification: Documentation: usage for diff combined commits git diff: improve range handling t/t3430: avoid undefined git diff behavior
2020-06-25Merge branch 'jk/complete-git-switch'Libravatar Junio C Hamano1-0/+455
The command line completion (in contrib/) learned to complete options that the "git switch" command takes. * jk/complete-git-switch: completion: improve handling of --orphan option of switch/checkout completion: improve handling of -c/-C and -b/-B in switch/checkout completion: improve handling of --track in switch/checkout completion: improve handling of --detach in checkout completion: improve completion for git switch with no options completion: improve handling of DWIM mode for switch/checkout completion: perform DWIM logic directly in __git_complete_refs completion: extract function __git_dwim_remote_heads completion: replace overloaded track term for __git_complete_refs completion: add tests showing subpar switch/checkout --orphan logic completion: add tests showing subpar -c/C argument completion completion: add tests showing subpar -c/-C startpoint completion completion: add tests showing subpar switch/checkout --track logic completion: add tests showing subar checkout --detach logic completion: add tests showing subpar DWIM logic for switch/checkout completion: add test showing subpar git switch completion
2020-06-25tests: reference `seen` wherever `pu` was referencedLibravatar Johannes Schindelin3-14/+14
As our test suite partially reflects how we work in the Git project, it is natural that the branch name `pu` was used in a couple places. Since that branch was renamed to `seen`, let's use the new name consistently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24testsvn: respect `init.defaultBranch`Libravatar Johannes Schindelin1-0/+6
The default name of the initial branch in new repositories can now be configured. The `testsvn` remote helper translates the remote Subversion repository's branch name `trunk` to the hard-coded name `master`. Clearly, the intention was to make the name align with Git's defaults. So while we are not talking about a newly-created repository in the `testsvn` context, it is a newly-created _Git_ repository, si it _still_ makes sense to use the overridden default name for the initial branch whenever users configured it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24remote: use the configured default branch name when appropriateLibravatar Johannes Schindelin1-1/+10
When guessing the default branch name of a remote, and there are no refs to guess from, we want to go with the preference specified by the user for the fall-back, i.e. the default name to be used for the initial branch of new repositories (because as far as the user is concerned, a remote that has no branches yet is a new repository). At the same time, when talking to an older Git server that does not report a symref for `HEAD` (but instead reports a commit hash), let's try to guess the configured default branch name first. If it does not match the reported commit hash, let's fall back to `master` as before. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24clone: use configured default branch name when appropriateLibravatar Johannes Schindelin1-0/+15
When cloning a repository without any branches, Git chooses a default branch name for the as-yet unborn branch. As part of the implicit initialization of the local repository, Git just learned to respect `init.defaultBranch` to choose a different initial branch name. We now really want that branch name to be used as a fall-back. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24init: allow setting the default for the initial branch name via the configLibravatar Don Goodman-Wilson1-0/+13
We just introduced the command-line option `--initial-branch=<branch-name>` to allow initializing a new repository with a different initial branch than the hard-coded one. To allow users to override the initial branch name more permanently (i.e. without having to specify the name manually for each and every `git init` invocation), let's introduce the `init.defaultBranch` config setting. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24init: allow specifying the initial branch name for the new repositoryLibravatar Johannes Schindelin1-0/+13
There is a growing number of projects and companies desiring to change the main branch name of their repositories (see e.g. https://twitter.com/mislav/status/1270388510684598272 for background on this). To change that branch name for new repositories, currently the only way to do that automatically is by copying all of Git's template directory, then hard-coding the desired default branch name into the `.git/HEAD` file, and then configuring `init.templateDir` to point to those copied template files. To make this process much less cumbersome, let's introduce a new option: `--initial-branch=<branch-name>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24submodule: fall back to remote's HEAD for missing remote.<name>.branchLibravatar Johannes Schindelin2-2/+21
When `remote.<name>.branch` is not configured, `git submodule update` currently falls back to using the branch name `master`. A much better idea, however, is to use the remote `HEAD`: on all Git servers running reasonably recent Git versions, the symref `HEAD` points to the main branch. Note: t7419 demonstrates that there _might_ be use cases out there that _expect_ `git submodule update --remote` to update submodules to the remote `master` branch even if the remote `HEAD` points to another branch. Arguably, this patch makes the behavior more intuitive, but there is a slight possibility that this might cause regressions in obscure setups. Even so, it should be okay to fix this behavior without anything like a longer transition period: - The `git submodule update --remote` command is not really common. - Current Git's behavior when running this command is outright confusing, unless the remote repository's current branch _is_ `master` (in which case the proposed behavior matches the old behavior). - If a user encounters a regression due to the changed behavior, the fix is actually trivial: setting `submodule.<name>.branch` to `master` will reinstate the old behavior. Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24send-pack/transport-helper: avoid mentioning a particular branchLibravatar Johannes Schindelin1-0/+6
When trying to push all matching branches, but none match, we offer a message suggesting to push the `master` branch. However, we want to step away from making that branch any more special than any other branch, so let's reword that message to mention no branch in particular. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24lib-submodule-update: pass 'test_must_fail' as an argumentLibravatar Denton Liu8-26/+84
When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-23fast-export: use xmemdupz() for anonymizing oidsLibravatar Jeff King1-0/+15
Our anonymize_mem() function is careful to take a ptr/len pair to allow storing binary tokens like object ids, as well as partial strings (e.g., just "foo" of "foo/bar"). But it duplicates the hash key using xstrdup()! That means that: - for a partial string, we'd store all bytes up to the NUL, even though we'd never look at anything past "len". This didn't produce wrong behavior, but was wasteful. - for a binary oid that doesn't contain a zero byte, we'd copy garbage bytes off the end of the array (though as long as nothing complained about reading uninitialized bytes, further reads would be limited by "len", and we'd produce the correct results) - for a binary oid that does contain a zero byte, we'd copy _fewer_ bytes than intended into the hashmap struct. When we later try to look up a value, we'd access uninitialized memory and potentially falsely claim that a particular oid is not present. The most common reason to store an oid is an anonymized gitlink, but our test case doesn't have any gitlinks at all. So let's add one whose oid contains a NUL and is present at two different paths. ASan catches the memory error, but even without it we can detect the bug because the oid is not anonymized the same way for both paths. And of course the fix is to copy the correct number of bytes. We don't technically need the appended NUL from xmemdupz(), but it doesn't hurt as an extra protection against anybody treating it like a string (plus a future patch will push us more in that direction). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-23t9351: derive anonymized tree checks from original repoLibravatar Jeff King1-10/+6
Our tests of the anonymized repo just hard-code the expected set of objects in the root and subdirectory trees. This makes them brittle to the test setup changing (e.g., adding new paths that need tested). Let's look at the original repo to compute our expected set of objects. Note that this isn't completely perfect (e.g., we still rely on there being only one tree in the root), but it does simplify later patches. 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 Schindelin28-93/+93
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-06-23commit-reach: avoid is_descendant_of() shimLibravatar Carlo Marcelo Arenas Belón1-1/+1
d91d6fbf26 (commit-reach: create repo_is_descendant_of(), 2020-06-17) adds a repository aware version of is_descendant_of() and a backward compatibility shim that is barely used. Update all callers to directly use the new repo_is_descendant_of() function instead; making the codebase simpler and pushing more the_repository references higher up the stack. Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-23http-push: ensure unforced pushes fail when data would be lostLibravatar brian m. carlson1-0/+16
When we push using the DAV-based protocol, the client is the one that performs the ref updates and therefore makes the checks to see whether an unforced push should be allowed. We make this check by determining if either (a) we lack the object file for the old value of the ref or (b) the new value of the ref is not newer than the old value, and in either case, reject the push. However, the ref_newer function, which performs this latter check, has an odd behavior due to the reuse of certain object flags. Specifically, it will incorrectly return false in its first invocation and then correctly return true on a subsequent invocation. This occurs because the object flags used by http-push.c are the same as those used by commit-reach.c, which implements ref_newer, and one piece of code misinterprets the flags set by the other. Note that this does not occur in all cases. For example, if the example used in the tests is changed to use one repository instead of two and rewind the head to add a commit, the test passes and we correctly reject the push. However, the example provided does trigger this behavior, and the code has been broken in this way since at least Git 2.0.0. To solve this problem, let's move the two sets of object flags so that they don't overlap, since we're clearly using them at the same time. The new set should not conflict with other usage because other users are either builtin code (which is not compiled into git http-push) or upload-pack (which we similarly do not use here). Reported-by: Michael Ward <mward@smartsoftwareinc.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22Merge branch 'es/worktree-duplicate-paths'Libravatar Junio C Hamano2-0/+45
The same worktree directory must be registered only once, but "git worktree move" allowed this invariant to be violated, which has been corrected. * es/worktree-duplicate-paths: worktree: make "move" refuse to move atop missing registered worktree worktree: generalize candidate worktree path validation worktree: prune linked worktree referencing main worktree path worktree: prune duplicate entries referencing same worktree path worktree: make high-level pruning re-usable worktree: give "should be pruned?" function more meaningful name worktree: factor out repeated string literal
2020-06-22Merge branch 'jt/redact-all-cookies'Libravatar Junio C Hamano1-14/+24
The interface to redact sensitive information in the trace output has been simplified. * jt/redact-all-cookies: http: redact all cookies, teach GIT_TRACE_REDACT=0
2020-06-22t/lib-git-svn: make hash size independentLibravatar brian m. carlson1-7/+10
The record size used in the git svn storage is four bytes plus the length of the binary hash. Pass the hash length into our Perl invocation and use it to compute the size of the records. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22diff-files: treat "i-t-a" files as "not-in-index"Libravatar Srinidhi Kaushik1-8/+45
The `diff-files' command and related commands which call the function `cmd_diff_files()', consider the "intent-to-add" files as a part of the index when comparing the work-tree against it. This was previously addressed in commits [1] and [2] by turning the option `--ita-invisible-in-index' (introduced in [3]) on by default. For `diff-files' (and `add -p' as a consequence) to show the i-t-a files as as new, `ita_invisible_in_index' will be enabled by default here as well. [1] 0231ae71d3 (diff: turn --ita-invisible-in-index on by default, 2018-05-26) [2] 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index", 2016-10-24) [3] b42b451919 (diff: add --ita-[in]visible-in-index, 2016-10-24) Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22worktree: drop get_worktrees() unused 'flags' argumentLibravatar Eric Sunshine1-1/+1
get_worktrees() accepts a 'flags' argument, however, there are no existing flags (the lone flag GWT_SORT_LINKED was recently retired) and no behavior which can be tweaked. Therefore, drop the 'flags' argument. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22t9101: make hash independentLibravatar brian m. carlson1-5/+7
Instead of hard-coding the object ID for our test .gitignore file, let's compute it. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22t9104: make hash size independentLibravatar brian m. carlson1-1/+2
The size of a record in the database used by git svn is four bytes plus the length of the binary hash. Instead of hard-coding 24, compute this value based on the size of the hash in use. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22t9100: make test work with SHA-256Libravatar brian m. carlson1-3/+16
Compute the relevant tree objects for SHA-256 and use those when appropriate instead of using the SHA-1 ones. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22t9108: make test hash independentLibravatar brian m. carlson1-2/+2
Instead of stripping off the first 41 characters of git log output, let's just strip off the first space-separated component, which will work for any size hash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22t9168: make test hash independentLibravatar brian m. carlson1-4/+4
Instead of stripping off the first 41 characters of git log output, let's just strip off the first space-separated component, which will work for any size hash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22t9109: make test hash independentLibravatar brian m. carlson1-3/+3
Instead of stripping off the first 41 characters of git log output, let's just strip off the first space-separated component, which will work for any size hash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19remote-testgit: adapt for object-formatLibravatar brian m. carlson1-0/+6
When using an algorithm other than SHA-1, we need the remote helper to advertise support for the object-format extension and provide information back to us so that we can properly parse refs and return data. Ensure that the test remote helper understands these extensions. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t5300: pass --object-format to git index-packLibravatar brian m. carlson1-4/+5
git index-pack by default reads the repository to determine the object format. However, when outside of a repository, it's necessary to specify the hash algorithm in use so that the pack can be properly indexed. Add an --object-format argument when invoking git index-pack outside of a repository. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>