summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-09-16t3201: test multiple branch filter combinationsLibravatar Aaron Lipman1-11/+36
Add tests covering the behavior of passing multiple contains/no-contains filters to git branch, e.g.: $ git branch --contains feature_a --contains feature_b $ git branch --no-contains feature_a --no-contains feature_b When passed more than one contains (or no-contains) filter, the tips of the branches returned must be reachable from any of the contains commits and from none of the the no-contains commits. This logic is useful to describe prior to enabling multiple merged/no-merged filters, so that future tests will demonstrate consistent behavior between merged/no-merged and contains/no-contains filters. Signed-off-by: Aaron Lipman <alipman88@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09Merge branch 'jt/interpret-branch-name-fallback'Libravatar Junio C Hamano1-0/+12
"git status" has trouble showing where it came from by interpreting reflog entries that recordcertain events, e.g. "checkout @{u}", and gives a hard/fatal error. Even though it inherently is impossible to give a correct answer because the reflog entries lose some information (e.g. "@{u}" does not record what branch the user was on hence which branch 'the upstream' needs to be computed, and even if the record were available, the relationship between branches may have changed), at least hide the error to allow "status" show its output. * jt/interpret-branch-name-fallback: wt-status: tolerate dangling marks refs: move dwim_ref() to header file sha1-name: replace unsigned int with option struct
2020-09-09Merge branch 'hv/ref-filter-misc'Libravatar Junio C Hamano1-0/+35
The "--format=" option to the "for-each-ref" command and friends learned a few more tricks, e.g. the ":short" suffix that applies to "objectname" now also can be used for "parent", "tree", etc. * hv/ref-filter-misc: ref-filter: add `sanitize` option for 'subject' atom pretty: refactor `format_sanitized_subject()` ref-filter: add `short` modifier to 'parent' atom ref-filter: add `short` modifier to 'tree' atom ref-filter: rename `objectname` related functions and fields ref-filter: modify error messages in `grab_objectname()` ref-filter: refactor `grab_objectname()` ref-filter: support different email formats
2020-09-09Merge branch 'ss/submodule-summary-in-c-fixes'Libravatar Junio C Hamano1-1/+1
Fixups to a topic in 'next'. * ss/submodule-summary-in-c-fixes: t7421: eliminate 'grep' check in t7421.4 for mingw compatibility submodule: fix style in function definition submodule: eliminate unused parameters from print_submodule_summary()
2020-09-09Merge branch 'es/worktree-repair'Libravatar Junio C Hamano2-0/+207
"git worktree" gained a "repair" subcommand to help users recover after moving the worktrees or repository manually without telling Git. Also, "git init --separate-git-dir" no longer corrupts administrative data related to linked worktrees. * es/worktree-repair: init: make --separate-git-dir work from within linked worktree init: teach --separate-git-dir to repair linked worktrees worktree: teach "repair" to fix outgoing links to worktrees worktree: teach "repair" to fix worktree back-links to main worktree worktree: add skeleton "repair" command
2020-09-09Merge branch 'tb/repack-clearing-midx'Libravatar Junio C Hamano1-2/+42
When a packfile is removed by "git repack", multi-pack-index gets cleared; the code was taught to do so less aggressively by first checking if the midx actually refers to a pack that no longer exists. * tb/repack-clearing-midx: midx: traverse the local MIDX first builtin/repack.c: invalidate MIDX only when necessary
2020-09-09Merge branch 'ss/submodule-summary-in-c'Libravatar Junio C Hamano2-0/+75
Yet another subcommand of "git submodule" is getting rewritten in C. * ss/submodule-summary-in-c: submodule: port submodule subcommand 'summary' from shell to C t7421: introduce a test script for verifying 'summary' output submodule: rename helper functions to avoid ambiguity submodule: remove extra line feeds between callback struct and macro
2020-09-03Merge branch 'mr/diff-hide-stat-wo-textual-change'Libravatar Junio C Hamano1-2/+36
"git diff --stat -w" showed 0-line changes for paths whose changes were only whitespaces, which was not intuitive. We now omit such paths from the stat output. * mr/diff-hide-stat-wo-textual-change: diff: teach --stat to ignore uninteresting modifications
2020-09-03Merge branch 'jt/lazy-fetch'Libravatar Junio C Hamano7-17/+64
Updates to on-demand fetching code in lazily cloned repositories. * jt/lazy-fetch: fetch: no FETCH_HEAD display if --no-write-fetch-head fetch-pack: remove no_dependents code promisor-remote: lazy-fetch objects in subprocess fetch-pack: do not lazy-fetch during ref iteration fetch: only populate existing_refs if needed fetch: avoid reading submodule config until needed fetch: allow refspecs specified through stdin negotiator/noop: add noop fetch negotiator
2020-09-03Merge branch 'jk/slimmed-down'Libravatar Junio C Hamano8-1674/+1
Trim an unused binary and turn a bunch of commands into built-in. * jk/slimmed-down: drop vcs-svn experiment make git-fast-import a builtin make git-bugreport a builtin make credential helpers builtins Makefile: drop builtins from MSVC pdb list
2020-09-03Merge branch 'jt/fetch-pack-loosen-validation-with-packfile-uri'Libravatar Junio C Hamano1-0/+53
Bugfix for "git fetch" when the packfile URI capability is in use. * jt/fetch-pack-loosen-validation-with-packfile-uri: fetch-pack: make packfile URIs work with transfer.fsckobjects fetch-pack: document only_packfile in get_pack() (various): document from_promisor parameter
2020-09-03Merge branch 'ss/t7401-modernize'Libravatar Junio C Hamano1-73/+76
Test clean-up. * ss/t7401-modernize: t7401: add a NEEDSWORK t7401: change indentation for enhanced readability t7401: change syntax of test_i18ncmp calls for clarity t7401: use 'short' instead of 'verify' and cut in rev-parse calls t7401: modernize style
2020-09-03Merge branch 'pw/rebase-i-more-options'Libravatar Junio C Hamano2-2/+180
"git rebase -i" learns a bit more options. * pw/rebase-i-more-options: t3436: do not run git-merge-recursive in dashed form rebase: add --reset-author-date rebase -i: support --ignore-date rebase -i: support --committer-date-is-author-date am: stop exporting GIT_COMMITTER_DATE rebase -i: add --ignore-whitespace flag
2020-09-02wt-status: tolerate dangling marksLibravatar Jonathan Tan1-0/+12
When a user checks out the upstream branch of HEAD, the upstream branch not being a local branch, and then runs "git status", like this: git clone $URL client cd client git checkout @{u} git status no status is printed, but instead an error message: fatal: HEAD does not point to a branch (This error message when running "git branch" persists even after checking out other things - it only stops after checking out a branch.) This is because "git status" reads the reflog when determining the "HEAD detached" message, and thus attempts to DWIM "@{u}", but that doesn't work because HEAD no longer points to a branch. Therefore, when calculating the status of a worktree, tolerate dangling marks. This is done by adding an additional parameter to dwim_ref() and repo_dwim_ref(). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-02fetch: no FETCH_HEAD display if --no-write-fetch-headLibravatar Jonathan Tan2-10/+15
887952b8c6 ("fetch: optionally allow disabling FETCH_HEAD update", 2020-08-18) introduced the ability to disable writing to FETCH_HEAD during fetch, but did not suppress the "<source> -> FETCH_HEAD" message when this ability is used. This message is misleading in this case, because FETCH_HEAD is not written. Also, because "fetch" is used to lazy-fetch missing objects in a partial clone, this significantly clutters up the output in that case since the objects to be fetched are potentially numerous. Therefore, suppress this message when --no-write-fetch-head is passed (but not when --dry-run is set). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31Merge branch 'ps/ref-transaction-hook'Libravatar Junio C Hamano1-3/+10
Code simplification by removing ineffective optimization. * ps/ref-transaction-hook: refs: remove lookup cache for reference-transaction hook
2020-08-31Merge branch 'jk/rev-input-given-fix'Libravatar Junio C Hamano2-0/+15
Feeding "$ZERO_OID" to "git log --ignore-missing --stdin", and running "git log --ignore-missing $ZERO_OID" fell back to start digging from HEAD; it has been corrected to become a no-op, like "git log --tags=no-tag-matches-this-pattern" does. * jk/rev-input-given-fix: revision: set rev_input_given in handle_revision_arg()
2020-08-31Merge branch 'jc/ident-whose-ident'Libravatar Junio C Hamano1-1/+12
Error message update. * jc/ident-whose-ident: ident: say whose identity is missing when giving user.name hint
2020-08-31Merge branch 'rs/checkout-no-overlay-pathspec-fix'Libravatar Junio C Hamano2-3/+28
"git restore/checkout --no-overlay" with wildcarded pathspec mistakenly removed matching paths in subdirectories, which has been corrected. * rs/checkout-no-overlay-pathspec-fix: checkout, restore: make pathspec recursive
2020-08-31Merge branch 'jk/index-pack-w-more-threads'Libravatar Junio C Hamano3-23/+35
Long ago, we decided to use 3 threads by default when running the index-pack task in parallel, which has been adjusted a bit upwards. * jk/index-pack-w-more-threads: index-pack: adjust default threading cap p5302: count up to online-cpus for thread tests p5302: disable thread-count parameter tests by default
2020-08-31Merge branch 'hv/ref-filter-trailers-atom-parsing-fix'Libravatar Junio C Hamano1-38/+18
The parser for "git for-each-ref --format=..." was too loose when parsing the "%(trailers...)" atom, and forgot that "trailers" and "trailers:<modifiers>" are the only two allowed forms, which has been corrected. * hv/ref-filter-trailers-atom-parsing-fix: ref-filter: 'contents:trailers' show error if `:` is missing t6300: unify %(trailers) and %(contents:trailers) tests
2020-08-31Merge branch 'jt/promisor-pack-fix'Libravatar Junio C Hamano1-0/+16
Updates into a lazy/partial clone with a submodule did not work well with transfer.fsckobjects set. * jt/promisor-pack-fix: fetch-pack: in partial clone, pass --promisor
2020-08-31Merge branch 'dd/diff-customize-index-line-abbrev'Libravatar Junio C Hamano4-21/+129
The output from the "diff" family of the commands had abbreviated object names of blobs involved in the patch, but its length was not affected by the --abbrev option. Now it is. * dd/diff-customize-index-line-abbrev: diff: index-line: respect --abbrev in object's name t4013: improve diff-post-processor logic
2020-08-31init: make --separate-git-dir work from within linked worktreeLibravatar Eric Sunshine1-2/+19
The intention of `git init --separate-work-dir=<path>` is to move the .git/ directory to a location outside of the main worktree. When used within a linked worktree, however, rather than moving the .git/ directory as intended, it instead incorrectly moves the worktree's .git/worktrees/<id> directory to <path>, thus disconnecting the linked worktree from its parent repository and breaking the worktree in the process since its local .git file no longer points at a location at which it can find the object database. Fix this broken behavior. An intentional side-effect of this change is that it also closes a loophole not caught by ccf236a23a (init: disallow --separate-git-dir with bare repository, 2020-08-09) in which the check to prevent --separate-git-dir being used in conjunction with a bare repository was unable to detect the invalid combination when invoked from within a linked worktree. Therefore, add a test to verify that this loophole is closed, as well. Reported-by: Henré Botha <henrebotha@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31init: teach --separate-git-dir to repair linked worktreesLibravatar Eric Sunshine1-0/+11
A linked worktree's .git file is a "gitfile" pointing at the .git/worktrees/<id> directory within the repository. When `git init --separate-git-dir=<path>` is used on an existing repository to relocate the repository's .git/ directory to a different location, it neglects to update the .git files of linked worktrees, thus breaking the worktrees by making it impossible for them to locate the repository. Fix this by teaching --separate-git-dir to repair the .git file of each linked worktree to point at the new repository location. Reported-by: Henré Botha <henrebotha@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31worktree: teach "repair" to fix outgoing links to worktreesLibravatar Eric Sunshine1-0/+86
The .git/worktrees/<id>/gitdir file points at the location of a linked worktree's .git file. Its content must be of the form /path/to/worktree/.git (from which the location of the worktree itself can be derived by stripping the "/.git" suffix). If the gitdir file is deleted or becomes corrupted or outdated, then Git will be unable to find the linked worktree. An easy way for the gitdir file to become outdated is for the user to move the worktree manually (without using "git worktree move"). Although it is possible to manually update the gitdir file to reflect the new linked worktree location, doing so requires a level of knowledge about worktree internals beyond what a user should be expected to know offhand. Therefore, teach "git worktree repair" how to repair broken or outdated .git/worktrees/<id>/gitdir files automatically. (For this to work, the command must either be invoked from within the worktree whose gitdir file requires repair, or from within the main or any linked worktree by providing the path of the broken worktree as an argument to "git worktree repair".) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31worktree: teach "repair" to fix worktree back-links to main worktreeLibravatar Eric Sunshine1-0/+82
The .git file in a linked worktree is a "gitfile" which points back to the .git/worktrees/<id> entry in the main worktree or bare repository. If a worktree's .git file is deleted or becomes corrupted or outdated, then the linked worktree won't know how to find the repository or any of its own administrative files (such as 'index', 'HEAD', etc.). An easy way for the .git file to become outdated is for the user to move the main worktree or bare repository. Although it is possible to manually update each linked worktree's .git file to reflect the new repository location, doing so requires a level of knowledge about worktree internals beyond what a user should be expected to know offhand. Therefore, teach "git worktree repair" how to repair broken or outdated worktree .git files automatically. (For this to work, the command must be invoked from within the main worktree or bare repository, or from within a worktree which has not become disconnected from the repository -- such as one which was created after the repository was moved.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: add `sanitize` option for 'subject' atomLibravatar Hariom Verma1-0/+7
Currently, subject does not take any arguments. This commit introduce `sanitize` formatting option to 'subject' atom. `subject:sanitize` - print sanitized subject line, suitable for a filename. e.g. %(subject): "the subject line" %(subject:sanitize): "the-subject-line" Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: add `short` modifier to 'parent' atomLibravatar Hariom Verma1-0/+6
Sometimes while using 'parent' atom, user might want to see abbrev hash instead of full 40 character hash. Just like 'objectname', it might be convenient for users to have the `:short` and `:short=<length>` option for printing 'parent' hash. Let's introduce `short` option to 'parent' atom. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: add `short` modifier to 'tree' atomLibravatar Hariom Verma1-0/+6
Sometimes while using 'tree' atom, user might want to see abbrev hash instead of full 40 character hash. Just like 'objectname', it might be convenient for users to have the `:short` and `:short=<length>` option for printing 'tree' hash. Let's introduce `short` option to 'tree' atom. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: support different email formatsLibravatar Hariom Verma1-0/+16
Currently, ref-filter only supports printing email with angle brackets. Let's add support for two more email options. - trim : for email without angle brackets. - localpart : for the part before the @ sign out of trimmed email Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27Merge branch 'jk/leakfix'Libravatar Junio C Hamano1-1/+1
Code clean-up. * jk/leakfix: submodule--helper: fix leak of core.worktree value config: fix leak in git_config_get_expiry_in_days() config: drop git_config_get_string_const() config: fix leaks from git_config_get_string_const() checkout: fix leak of non-existent branch names submodule--helper: use strbuf_release() to free strbufs clear_pattern_list(): clear embedded hashmaps
2020-08-27t7421: eliminate 'grep' check in t7421.4 for mingw compatibilityLibravatar Shourya Shukla1-1/+1
The 'grep' check in test 4 of t7421 resulted in the failure of t7421 on Windows due to a different error message error: cannot spawn git: No such file or directory instead of fatal: exec 'rev-parse': cd to 'my-subm' failed: No such file or directory Tighten up the check to compute 'src_abbrev' by guarding the 'verify_submodule_committish()' call using `p->status !='D'`, so that the former isn't called in case of non-existent submodule directory, consequently, there is no such error message on any execution environment. The same need not be implemented for 'dst_abbrev' and is rather redundant since the conditional 'if (S_ISGITLINK(p->mod_dst))' already guards the 'verify_submodule_committish()' when we have a status of 'D'. Therefore, eliminate the 'grep' check in t7421. Instead, verify the absence of an error message by doing a 'test_must_be_empty' on the file containing the error. Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27worktree: add skeleton "repair" commandLibravatar Eric Sunshine1-0/+11
Worktree administrative files can become corrupted or outdated due to external factors. Although, it is often possible to recover from such situations by hand-tweaking these files, doing so requires intimate knowledge of worktree internals. While information necessary to make such repairs manually can be obtained from git-worktree.txt and gitrepository-layout.txt, we can assist users more directly by teaching git-worktree how to repair its administrative files itself (at least to some extent). Therefore, add a "git worktree repair" command which attempts to correct common problems which may arise due to factors beyond Git's control. At this stage, the "repair" command is a mere skeleton; subsequent commits will flesh out the functionality. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26t3436: do not run git-merge-recursive in dashed formLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26builtin/repack.c: invalidate MIDX only when necessaryLibravatar Taylor Blau1-2/+42
In 525e18c04b (midx: clear midx on repack, 2018-07-12), 'git repack' learned to remove a multi-pack-index file if it added or removed a pack from the object store. This mechanism is a little over-eager, since it is only necessary to drop a MIDX if 'git repack' removes a pack that the MIDX references. Adding a pack outside of the MIDX does not require invalidating the MIDX, and likewise for removing a pack the MIDX does not know about. Teach 'git repack' to check for this by loading the MIDX, and checking whether the to-be-removed pack is known to the MIDX. This requires a slightly odd alternation to a test in t5319, which is explained with a comment. A new test is added to show that the MIDX is left alone when both packs known to it are marked as .keep, but two packs unknown to it are removed and combined into one new pack. Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26revision: set rev_input_given in handle_revision_arg()Libravatar Jeff King2-0/+15
Commit 7ba826290a (revision: add rev_input_given flag, 2017-08-02) added a flag to rev_info to tell whether we got any revision arguments. As explained there, this is necessary because some revision arguments may not produce any pending traversal objects, but should still inhibit default behaviors (e.g., a glob that matches nothing). However, it only set the flag in the globbing code, but not for revisions we get on the command-line or via stdin. This leads to two problems: - the command-line code keeps its own separate got_rev_arg flag; this isn't wrong, but it's confusing and an extra maintenance burden - even specifically-named rev arguments might end up not adding any pending objects: if --ignore-missing is set, then specifying a missing object is a noop rather than an error. And that leads to some user-visible bugs: - when deciding whether a default rev like "HEAD" should kick in, we check both got_rev_arg and rev_input_given. That means that "--ignore-missing $ZERO_OID" works on the command-line (where we set got_rev_arg) but not on --stdin (where we don't) - when rev-list decides whether it should complain that it wasn't given a starting point, it relies on rev_input_given. So it can't even get the command-line "--ignore-missing $ZERO_OID" right Let's consistently set the flag if we got any revision argument. That lets us clean up the redundant got_rev_arg, and fixes both of those bugs (but note there are three new tests: we'll confirm the already working git-log command-line case). A few implementation notes: - conceptually we want to set the flag whenever handle_revision_arg() finds an actual revision arg ("handles" it, you might say). But it covers a ton of cases with early returns. Rather than annotating each one, we just wrap it and use its success exit-code to set the flag in one spot. - the new rev-list test is in t6018, which is titled to cover globs. This isn't exactly a glob, but it made sense to stick it with the other tests that handle the "even though we got a rev, we have no pending objects" case, which are globs. - the tests check for the oid of a missing object, which it's pretty clear --ignore-missing should ignore. You can see the same behavior with "--ignore-missing a-ref-that-does-not-exist", because --ignore-missing treats them both the same. That's perhaps less clearly correct, and we may want to change that in the future. But the way the code and tests here are written, we'd continue to do the right thing even if it does. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-25refs: remove lookup cache for reference-transaction hookLibravatar Patrick Steinhardt1-3/+10
When adding the reference-transaction hook, there were concerns about the performance impact it may have on setups which do not make use of the new hook at all. After all, it gets executed every time a reftx is prepared, committed or aborted, which linearly scales with the number of reference-transactions created per session. And as there are code paths like `git push` which create a new transaction for each reference to be updated, this may translate to calling `find_hook()` quite a lot. To address this concern, a cache was added with the intention to not repeatedly do negative hook lookups. Turns out this cache caused a regression, which was fixed via e5256c82e5 (refs: fix interleaving hook calls with reference-transaction hook, 2020-08-07). In the process of discussing the fix, we realized that the cache doesn't really help even in the negative-lookup case. While performance tests added to benchmark this did show a slight improvement in the 1% range, this really doesn't warrent having a cache. Furthermore, it's quite flaky, too. E.g. running it twice in succession produces the following results: Test master pks-reftx-hook-remove-cache -------------------------------------------------------------------------- 1400.2: update-ref 2.79(2.16+0.74) 2.73(2.12+0.71) -2.2% 1400.3: update-ref --stdin 0.22(0.08+0.14) 0.21(0.08+0.12) -4.5% Test master pks-reftx-hook-remove-cache -------------------------------------------------------------------------- 1400.2: update-ref 2.70(2.09+0.72) 2.74(2.13+0.71) +1.5% 1400.3: update-ref --stdin 0.21(0.10+0.10) 0.21(0.08+0.13) +0.0% One case notably absent from those benchmarks is a single executable searching for the hook hundreds of times, which is exactly the case for which the negative cache was added. p1400.2 will spawn a new update-ref for each transaction and p1400.3 only has a single reference-transaction for all reference updates. So this commit adds a third benchmark, which performs an non-atomic push of a thousand references. This will create a new reference transaction per reference. But even for this case, the negative cache doesn't consistently improve performance: Test master pks-reftx-hook-remove-cache -------------------------------------------------------------------------- 1400.4: nonatomic push 6.63(6.50+0.13) 6.81(6.67+0.14) +2.7% 1400.4: nonatomic push 6.35(6.21+0.14) 6.39(6.23+0.16) +0.6% 1400.4: nonatomic push 6.43(6.31+0.13) 6.42(6.28+0.15) -0.2% So let's just remove the cache altogether to simplify the code. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-24fetch-pack: make packfile URIs work with transfer.fsckobjectsLibravatar Jonathan Tan1-0/+53
When fetching with packfile URIs and transfer.fsckobjects=1, use the --fsck-objects instead of the --strict flag when invoking index-pack so that links are not checked, only objects. This is because incomplete links are expected. (A subsequent connectivity check will be done when all the packs have been downloaded regardless of whether transfer.fsckobjects is set.) This is similar to 98a2ea46c2 ("fetch-pack: do not check links for partial fetch", 2018-03-15), but for packfile URIs instead of partial clones. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-24Merge branch 'rs/patch-id-with-incomplete-line'Libravatar Junio C Hamano1-0/+23
The patch-id computation did not ignore the "incomplete last line" marker like whitespaces. * rs/patch-id-with-incomplete-line: patch-id: ignore newline at end of file in diff_flush_patch_id()
2020-08-24Merge branch 'jc/no-update-fetch-head'Libravatar Junio C Hamano2-2/+20
"git fetch" learned --no-write-fetch-head option to avoid writing the FETCH_HEAD file. * jc/no-update-fetch-head: fetch: optionally allow disabling FETCH_HEAD update
2020-08-24Merge branch 'en/dir-nonbare-embedded'Libravatar Junio C Hamano1-4/+20
"ls-files -o" mishandled the top-level directory of another git working tree that hangs in the current git working tree. * en/dir-nonbare-embedded: dir: avoid prematurely marking nonbare repositories as matches t3000: fix some test description typos
2020-08-24Merge branch 'ds/midx-repack-to-batch-size'Libravatar Junio C Hamano1-0/+18
The "--batch-size" option of "git multi-pack-index repack" command is now used to specify that very small packfiles are collected into one until the total size roughly exceeds it. * ds/midx-repack-to-batch-size: multi-pack-index: repack batches below --batch-size
2020-08-24Merge branch 'es/init-no-separate-git-dir-in-bare'Libravatar Junio C Hamano1-0/+13
The purpose of "git init --separate-git-dir" is to initialize a new project with the repository separate from the working tree, or, in the case of an existing project, to move the repository (the .git/ directory) out of the working tree. It does not make sense to use --separate-git-dir with a bare repository for which there is no working tree, so disallow its use with bare repositories. * es/init-no-separate-git-dir-in-bare: init: disallow --separate-git-dir with bare repository
2020-08-22checkout, restore: make pathspec recursiveLibravatar René Scharfe2-3/+28
The pathspec given to git checkout and git restore is used with both tree_entry_interesting (via read_tree_recursive) and match_pathspec (via ce_path_match). The latter effectively only supports recursive matching regardless of the value of the pathspec flag "recursive", which is unset here. That causes different match results for pathspecs with wildcards, and can lead checkout and restore in no-overlay mode to remove entries instead of modifying them. Enable recursive matching for both checkout and restore to make matching consistent. Setting the flag in checkout_main() technically also affects git switch, but since that command doesn't accept pathspecs at all this has no actual consequence. Reported-by: Sergii Shkarnikov <sergii.shkarnikov@globallogic.com> Initial-test-by: Sergii Shkarnikov <sergii.shkarnikov@globallogic.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21ident: say whose identity is missing when giving user.name hintLibravatar Junio C Hamano1-1/+12
If `user.name` and `user.email` have not been configured and the user invokes: git commit --author=... without specifying the committer identity, then Git errors out with a message asking the user to configure `user.name` and `user.email` but doesn't tell the user which attribution was missing. This can be confusing for a user new to Git who isn't aware of the distinction between user, author, and committer. Give such users a bit more help by extending the error message to also say which attribution is expected. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21ref-filter: 'contents:trailers' show error if `:` is missingLibravatar Hariom Verma1-0/+8
The 'contents' atom does not show any error if used with 'trailers' atom and colon is missing before trailers arguments. e.g %(contents:trailersonly) works, while it shouldn't. It is definitely not an expected behavior. Let's fix this bug. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21diff: index-line: respect --abbrev in object's nameLibravatar Đoàn Trần Công Danh4-0/+90
A handful of Git's commands respect `--abbrev' for customizing length of abbreviation of object names. For diff-family, Git supports 2 different options for 2 different purposes, `--full-index' for showing diff-patch object's name in full, and `--abbrev' to customize the length of object names in diff-raw and diff-tree header lines, without any options to customise the length of object names in diff-patch format. When working with diff-patch format, we only have two options, either full index, or default abbrev length. Although, that behaviour is documented, it doesn't stop users from trying to use `--abbrev' with the hope of customising diff-patch's objects' name's abbreviation. Let's allow the blob object names shown on the "index" line to be abbreviated to arbitrary length given via the "--abbrev" option. To preserve backward compatibility with old script that specify both `--full-index' and `--abbrev', always show full object id if `--full-index' is specified. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21t4013: improve diff-post-processor logicLibravatar brian m. carlson1-21/+39
From 72f936b1 (t4013: make test hash independent, 2020-02-07), we started to adjust metadata of git-diff's output in order to ignore uninteresting metadata which is dependent of underlying hash algorithm. However, we forgot to special case all-zero object names, which is special for missing objects, in consequence, we could't catch possible future bugs where object names is all-zeros including but not limited to: * show intend-to-add entry * deleted entry * diff between index and working tree with new file We also mistakenly munged file-modes as if they were object names abbreviated to 6 hexadecimal digits. In addition, in the upcoming change, we would like to test for customizing the length of abbreviated blob objects on the index line, which is not supported by current diff-processor logic. Let's fix the bug for all-zero object names, and file modes. While we're at it, support abbreviation of object names up to 16 bytes. Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21t6300: unify %(trailers) and %(contents:trailers) testsLibravatar Hariom Verma1-42/+14
Currently, there are different tests for testing %(trailers) and %(contents:trailers) causing redundant copy. Its time to get rid of duplicate code. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>