summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-07-02t3311: use test_commit_bulkLibravatar Jeff King1-5/+5
One of the tests in t3311 creates 300 commits by running "test_commit" in a loop. This requires 900 processes. Instead, we can use test_commit_bulk to do it with only four. This improves the runtime of the script from: Benchmark #1: ./t3311-notes-merge-fanout.sh --root=/var/ram/git-tests Time (mean ± σ): 5.821 s ± 0.691 s [User: 3.146 s, System: 2.782 s] Range (min … max): 4.783 s … 6.841 s 10 runs to: Benchmark #1: ./t3311-notes-merge-fanout.sh --root=/var/ram/git-tests Time (mean ± σ): 1.743 s ± 0.116 s [User: 1.144 s, System: 0.691 s] Range (min … max): 1.629 s … 1.994 s 10 runs for an average speedup of over 70%. Unfortunately we still have to run 300 instances of "git notes add", since the point is to test the fanout that comes from adding notes one by one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-02t5310: increase the number of bitmapped commitsLibravatar Jeff King1-1/+1
The bitmap index we compute in t5310 has only 20 commits in it. This gives poor coverage of bitmap_writer_select_commits(), which simply writes a bitmap for everything when there are fewer than 100 commits. Let's bump the number of commits in the test to cover the more complex code paths (this does drop coverage of the individual lines of the trivial path, but the complex path does everything it does and more). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-02test-lib: introduce test_commit_bulkLibravatar Jeff King2-12/+126
Some tests need to create a string of commits. Doing this with test_commit is very heavy-weight, as it needs at least one process per commit (and in fact, uses several). For bulk creation, we can do much better by using fast-import, but it's often a pain to generate the input. Let's provide a helper to do so. We'll use t5310 as a guinea pig, as it has three 10-commit loops. Here are hyperfine results before and after: [before] Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests Time (mean ± σ): 2.846 s ± 0.305 s [User: 3.042 s, System: 0.919 s] Range (min … max): 2.250 s … 3.210 s 10 runs [after] Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests Time (mean ± σ): 2.210 s ± 0.174 s [User: 2.570 s, System: 0.604 s] Range (min … max): 1.999 s … 2.590 s 10 runs So we're over 20% faster, while making the callers slightly shorter. We added a lot more lines in test-lib-function.sh, of course, and the helper is way more featureful than we need here. But my hope is that it will be flexible enough to use in more places. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21Merge branch 'jt/partial-clone-missing-ref-delta-base'Libravatar Junio C Hamano1-13/+99
"git fetch" into a lazy clone forgot to fetch base objects that are necessary to complete delta in a thin packfile, which has been corrected. * jt/partial-clone-missing-ref-delta-base: t5616: cover case of client having delta base t5616: use correct flag to check object is missing index-pack: prefetch missing REF_DELTA bases t5616: refactor packfile replacement
2019-06-21Merge branch 'ml/userdiff-rust'Libravatar Junio C Hamano5-0/+21
The pattern "git diff/grep" use to extract funcname and words boundary for Rust has been added. * ml/userdiff-rust: userdiff: two simplifications of patterns for rust userdiff: add built-in pattern for rust
2019-06-17Merge branch 'xl/record-partial-clone-origin'Libravatar Junio C Hamano1-3/+13
When creating a partial clone, the object filtering criteria is recorded for the origin of the clone, but this incorrectly used a hardcoded name "origin" to name that remote; it has been corrected to honor the "--origin <name>" option. * xl/record-partial-clone-origin: clone: respect user supplied origin name when setting up partial clone
2019-06-17Merge branch 'pb/request-pull-verify-remote-ref'Libravatar Junio C Hamano1-0/+53
"git request-pull" learned to warn when the ref we ask them to pull from in the local repository and in the published repository are different. * pb/request-pull-verify-remote-ref: request-pull: warn if the remote object is not the same as the local one request-pull: quote regex metacharacters in local ref
2019-06-17Merge branch 'sw/git-p4-unshelve-branched-files'Libravatar Junio C Hamano1-1/+7
"git p4" update. * sw/git-p4-unshelve-branched-files: git-p4: allow unshelving of branched files
2019-06-17Merge branch 'bl/userdiff-octave'Libravatar Junio C Hamano5-0/+18
The pattern "git diff/grep" use to extract funcname and words boundary for Matlab has been extend to cover Octave, which is more or less equivalent. * bl/userdiff-octave: userdiff: fix grammar and style issues userdiff: add Octave
2019-06-17Merge branch 'ba/clone-remote-submodules'Libravatar Junio C Hamano1-0/+54
"git clone --recurse-submodules" learned to set up the submodules to ignore commit object names recorded in the superproject gitlink and instead use the commits that happen to be at the tip of the remote-tracking branches from the get-go, by passing the new "--remote-submodules" option. * ba/clone-remote-submodules: clone: add `--remote-submodules` flag
2019-06-17Merge branch 'vv/merge-squash-with-explicit-commit'Libravatar Junio C Hamano1-0/+6
"git merge --squash" is designed to update the working tree and the index without creating the commit, and this cannot be countermanded by adding the "--commit" option; the command now refuses to work when both options are given. * vv/merge-squash-with-explicit-commit: merge: refuse --commit with --squash
2019-06-17Merge branch 'js/bundle-verify-require-object-store'Libravatar Junio C Hamano1-0/+6
"git bundle verify" needs to see if prerequisite objects exist in the receiving repository, but the command did not check if we are in a repository upfront, which has been corrected. * js/bundle-verify-require-object-store: bundle verify: error out if called without an object database
2019-06-17Merge branch 'jk/am-i-resolved-fix'Libravatar Junio C Hamano1-0/+52
"git am -i --resolved" segfaulted after trying to see a commit as if it were a tree, which has been corrected. * jk/am-i-resolved-fix: am: fix --interactive HEAD tree resolution am: drop tty requirement for --interactive am: read interactive input from stdin am: simplify prompt response handling
2019-06-17Merge branch 'jk/HEAD-symref-in-xfer-namespaces'Libravatar Junio C Hamano1-0/+28
The server side support for "git fetch" used to show incorrect value for the HEAD symbolic ref when the namespace feature is in use, which has been corrected. * jk/HEAD-symref-in-xfer-namespaces: upload-pack: strip namespace from symref data
2019-06-17Merge branch 'ew/server-info-remove-crufts'Libravatar Junio C Hamano1-0/+2
"git update-server-info" used to leave stale packfiles in its output, which has been corrected. * ew/server-info-remove-crufts: server-info: do not list unlinked packs
2019-06-13Merge branch 'pw/rebase-edit-message-for-replayed-merge'Libravatar Junio C Hamano1-0/+13
A "merge -c" instruction during "git rebase --rebase-merges" should give the user a chance to edit the log message, even when there is otherwise no need to create a new merge and replace the existing one (i.e. fast-forward instead), but did not. Which has been corrected. * pw/rebase-edit-message-for-replayed-merge: rebase -r: always reword merge -c
2019-06-13Merge branch 'ew/update-server-info'Libravatar Junio C Hamano1-0/+41
"git update-server-info" learned not to rewrite the file with the same contents. * ew/update-server-info: update-server-info: avoid needless overwrites
2019-06-13Merge branch 'jk/help-unknown-ref-fix'Libravatar Junio C Hamano1-0/+20
Improve the code to show args with potential typo that cannot be interpreted as a commit-ish. * jk/help-unknown-ref-fix: help_unknown_ref(): check for refname ambiguity help_unknown_ref(): duplicate collected refnames
2019-06-13Merge branch 'dl/format-patch-notes-config'Libravatar Junio C Hamano1-0/+70
"git format-patch" learns a configuration to set the default for its --notes=<ref> option. * dl/format-patch-notes-config: format-patch: teach format.notes config option git-format-patch.txt: document --no-notes option
2019-06-13Merge branch 'nd/merge-quit'Libravatar Junio C Hamano1-0/+26
"git merge" learned "--quit" option that cleans up the in-progress merge while leaving the working tree and the index still in a mess. * nd/merge-quit: merge: add --quit merge: remove drop_save() in favor of remove_merge_branch_state()
2019-06-13Merge branch 'ab/fail-prereqs-in-test'Libravatar Junio C Hamano7-10/+43
Developer support to emulate unsatisfied prerequisites in tests to ensure that the remainer of the tests still succeeds when tests with prerequisites are skipped. * ab/fail-prereqs-in-test: tests: add a special setup where prerequisites fail
2019-06-13Merge branch 'nd/corrupt-worktrees'Libravatar Junio C Hamano1-0/+12
"git worktree add" used to fail when another worktree connected to the same repository was corrupt, which has been corrected. * nd/corrupt-worktrees: worktree add: be tolerant of corrupt worktrees
2019-06-13Merge branch 'js/rebase-cleanup'Libravatar Junio C Hamano1-1/+1
Update supporting parts of "git rebase" to remove code that should no longer be used. * js/rebase-cleanup: rebase: fold git-rebase--common into the -p backend sequencer: the `am` and `rebase--interactive` scripts are gone .gitignore: there is no longer a built-in `git-rebase--interactive` t3400: stop referring to the scripted rebase Drop unused git-rebase--am.sh
2019-06-13Merge branch 'nd/worktree-name-sanitization'Libravatar Junio C Hamano1-0/+5
In recent versions of Git, per-worktree refs are exposed in refs/worktrees/<wtname>/ hierarchy, which means that worktree names must be a valid refname component. The code now sanitizes the names given to worktrees, to make sure these refs are well-formed. * nd/worktree-name-sanitization: worktree add: sanitize worktree names
2019-06-13Merge branch 'en/fast-export-encoding'Libravatar Junio C Hamano4-9/+91
The "git fast-export/import" pair has been taught to handle commits with log messages in encoding other than UTF-8 better. * en/fast-export-encoding: fast-export: do automatic reencoding of commit messages only if requested fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8 fast-export: avoid stripping encoding header if we cannot reencode fast-import: support 'encoding' commit header t9350: fix encoding test to actually test reencoding
2019-06-13Merge branch 'sb/format-patch-base-patch-id-fix'Libravatar Junio C Hamano1-3/+29
The "--base" option of "format-patch" computed the patch-ids for prerequisite patches in an unstable way, which has been updated to compute in a way that is compatible with "git patch-id --stable". * sb/format-patch-base-patch-id-fix: format-patch: make --base patch-id output stable format-patch: inform user that patch-id generation is unstable
2019-06-13Merge branch 'nd/init-relative-template-fix'Libravatar Junio C Hamano2-4/+4
A relative pathname given to "git init --template=<path> <repo>" ought to be relative to the directory "git init" gets invoked in, but it instead was made relative to the repository, which has been corrected. * nd/init-relative-template-fix: init: make --template path relative to $CWD
2019-06-13Merge branch 'ab/send-email-transferencoding-fix'Libravatar Junio C Hamano1-20/+82
Since "git send-email" learned to take 'auto' as the value for the transfer-encoding, it by mistake stopped honoring the values given to the configuration variables sendemail.transferencoding and/or sendemail.<ident>.transferencoding. This has been corrected to (finally) redoing the order of setting the default, reading the configuration and command line options. * ab/send-email-transferencoding-fix: send-email: fix regression in sendemail.identity parsing send-email: document --no-[to|cc|bcc] send-email: fix broken transferEncoding tests send-email: remove cargo-culted multi-patch pattern in tests send-email: do defaults -> config -> getopt in that order send-email: rename the @bcclist variable for consistency send-email: move the read_config() function above getopts
2019-06-11t5616: cover case of client having delta baseLibravatar Jonathan Tan1-11/+28
When fetching into a partial clone, Git first prefetches missing REF_DELTA bases from the promisor remote. (This feature was introduced in [1].) But as can be seen in a recent test coverage report [2], the case in which a REF_DELTA base is already present is not covered by tests. Extend the tests slightly to cover this case. [1] 8a30a1efd1 ("index-pack: prefetch missing REF_DELTA bases", 2019-05-15). [2] https://public-inbox.org/git/396091fc-5572-19a5-4f18-61c258590dd5@gmail.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-11t5616: use correct flag to check object is missingLibravatar Jonathan Tan1-1/+1
If we want to check whether an object is missing, the correct flag to pass to rev-list is --ignore-missing; --exclude-promisor-objects will exclude any object that came from the promisor remote, whether it is present or missing. Use the correct flag. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-06Merge branch 'en/merge-directory-renames-fix'Libravatar Junio C Hamano1-0/+116
Recent code restructuring of merge-recursive engine introduced a regression dealing with rename/add conflict. * en/merge-directory-renames-fix: merge-recursive: restore accidentally dropped setting of path
2019-06-05merge-recursive: restore accidentally dropped setting of pathLibravatar Elijah Newren1-0/+116
In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs to a diff_filespec", 2019-04-05), we actually switched from (oid,mode,path) triplets to a diff_filespec -- but most callsites in the patch only needed to worry about oid and mode so the commit message focused on that. The oversight in the commit message apparently spilled over to the code as well; one of the dozen or so callsites accidentally dropped the setting of the path in the conversion. Restore the path setting in that location. Also, this pointed out that our testsuite was lacking a good rename/add test, at least one that involved the need for merge content with the rename. Add such a test, and since rename/add vs. add/rename could possibly be important, redo the merge the opposite direction to make sure we don't have issues with the direction of the merge. These testcases failed before restoring the setting of path, but with the paths appropriately set the testcases both pass. Reported-by: Ben Humphreys <behumphreys@atlassian.com> Based-on-patch-by: SZEDER Gábor <szeder.dev@gmail.com> Tested-by: Ben Humphreys <behumphreys@atlassian.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-03Merge branch 'cc/list-objects-filter-wo-sparse-path'Libravatar Junio C Hamano2-84/+26
Disable "--filter=sparse:path=<path>" that would allow reading from paths on the filesystem. * cc/list-objects-filter-wo-sparse-path: list-objects-filter: disable 'sparse:path' filters
2019-05-30Merge branch 'js/rebase-deprecate-preserve-merges'Libravatar Junio C Hamano2-7/+13
A bit more leftover clean-up to deprepcate "rebase -p". * js/rebase-deprecate-preserve-merges: rebase docs: recommend `-r` over `-p` docs: say that `--rebase=preserve` is deprecated tests: mark a couple more test cases as requiring `rebase -p`
2019-05-30Merge branch 'sg/trace2-rename'Libravatar Junio C Hamano5-32/+32
Rename environment variables that are used to control the "trace2" mechanism to a more readable name. * sg/trace2-rename: trace2: document the supported values of GIT_TRACE2* env variables trace2: rename environment variables to GIT_TRACE2*
2019-05-30Merge branch 'nd/diff-parseopt'Libravatar Junio C Hamano4-0/+94
A brown-paper-bag bugfix to a change already in 'master'. * nd/diff-parseopt: parse-options: check empty value in OPT_INTEGER and OPT_ABBREV diff-parseopt: restore -U (no argument) behavior diff-parseopt: correct variable types that are used by parseopt
2019-05-29clone: respect user supplied origin name when setting up partial cloneLibravatar Xin Li1-3/+13
Signed-off-by: Xin Li <delphij@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-29list-objects-filter: disable 'sparse:path' filtersLibravatar Christian Couder2-84/+26
If someone wants to use as a filter a sparse file that is in the repository, something like "--filter=sparse:oid=<ref>:<path>" already works. So 'sparse:path' is only interesting if the sparse file is not in the repository. In this case though the current implementation has a big security issue, as it makes it possible to ask the server to read any file, like for example /etc/password, and to explore the filesystem, as well as individual lines of files. If someone is interested in using a sparse file that is not in the repository as a filter, then at the minimum a config option, such as "uploadpack.sparsePathFilter", should be implemented first to restrict the directory from which the files specified by 'sparse:path' can be read. For now though, let's just disable 'sparse:path' filters. Helped-by: Matthew DeVore <matvore@google.com> Helped-by: Jeff Hostetler <git@jeffhostetler.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-29diff-parseopt: restore -U (no argument) behaviorLibravatar Nguyễn Thái Ngọc Duy4-0/+94
Before d473e2e0e8 (diff.c: convert -U|--unified, 2019-01-27), -U and --unified are implemented with a custom parser opt_arg() in diff.c. I didn't check this code carefully and not realize that it's the equivalent of PARSE_OPT_NONEG | PARSE_OPT_OPTARG. In other words, if -U is specified without any argument, the option should be accepted, and the default value should be used. Without PARSE_OPT_OPTARG, parse_options() will reject this case and cause a regression. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-29send-email: fix regression in sendemail.identity parsingLibravatar Ævar Arnfjörð Bjarmason1-0/+64
Fix a regression in my recent 3494dfd3ee ("send-email: do defaults -> config -> getopt in that order", 2019-05-09). I missed that the $identity variable needs to be extracted from the command-line before we do the config reading, as it determines which config variable we should read first. See [1] for the report. The sendemail.identity feature was added back in 34cc60ce2b ("send-email: Add support for SSL and SMTP-AUTH", 2007-09-03), there were no tests to assert that it worked properly. So let's fix both the regression, and add some tests to assert that this is being parsed properly. While I'm at it I'm adding a --no-identity option to go with --[to|cc|bcc] variable, since the semantics are similar. It's like to/cc/bcc except that unlike those we don't support multiple identities, but we could now easily add it support for it if anyone cares. In just fixing the --identity command-line parsing bug I discovered that a narrow fix to that wouldn't do. In read_config() we had a state machine that would only set config values if they weren't set already, and thus by proxy we wouldn't e.g. set "to" based on sendemail.to if we'd seen sendemail.gmail.to before, with --identity=gmail. I'd modified some of the relevant code in 3494dfd3ee, but just reverting to that wouldn't do, since it would bring back the regression fixed in that commit. Refactor read_config() do what we actually mean here. We don't want to set a given sendemail.VAR if a sendemail.$identity.VAR previously set it. The old code was conflating this desire with the hardcoded defaults for these variables, and as discussed in 3494dfd3ee that was never going to work. Instead pass along the state of whether an identity config set something before, as distinguished from the state of the default just being false, or the default being a non-bool or true (e.g. --transferencoding). I'm still not happy with the test coverage here, e.g. there's nothing testing sendemail.smtpEncryption, but I only have so much time to fix this code. 1. https://public-inbox.org/git/5cddeb61.1c69fb81.47ed4.e648@mx.google.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28tests: mark a couple more test cases as requiring `rebase -p`Libravatar Johannes Schindelin2-7/+13
The `--preserve-merges` option has been deprecated, and as a consequence we started to mark test cases that require that option to be supported, in preparation for removing that support eventually. Since we marked those test cases, a couple more crept into the test suite, and with this patch, we mark them, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28request-pull: warn if the remote object is not the same as the local oneLibravatar Paolo Bonzini1-0/+35
In some cases, git request-pull might be invoked with remote and local objects that differ even though they point to the same commit. For example, the remote object might be a lightweight tag vs. an annotated tag on the local side; or the user might have reworded the tag locally and forgotten to push it. When this happens git-request-pull will not warn, because it only checks that "git ls-remote" returns an SHA1 that matches the local commit (known as $headrev in the script). This patch makes git-request-pull retrieve the tag object SHA1 while processing the "git ls-remote" output, so that it can be matched against the local object. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28request-pull: quote regex metacharacters in local refLibravatar Paolo Bonzini1-0/+18
The local part of the third argument of git-request-pull is used in a regular expression without quoting it. Use qr{} and \Q\E to ensure that e.g. a period in a tag name does not match any character on the remote side. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28bundle verify: error out if called without an object databaseLibravatar Johannes Schindelin1-0/+6
The deal with bundles is: they really are thin packs, with very little sugar on top. So we really need a repository (or more appropriately, an object database) to work with, when asked to verify a bundle. Let's error out with a useful error message if `git bundle verify` is called without such an object database to work with. Reported by Konstantin Ryabitsev. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28merge: refuse --commit with --squashLibravatar Vishal Verma1-0/+6
Convert option_commit to tristate, representing the states of 'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in place, check whether option_commit was enabled by cli when squashing a merge. If so, error out, as this is not supported. Previously, when --squash was supplied, 'option_commit' was silently dropped. This could have been surprising to a user who tried to override the no-commit behavior of squash using --commit explicitly. Add a note to the --squash option for git-merge to clarify the incompatibility, and add a test case to t7600-merge.sh Cc: Junio C Hamano <gitster@pobox.com> Cc: Rafael Ascensão <rafa.almas@gmail.com> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Vishal Verma <vishal@stellar.sh> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28server-info: do not list unlinked packsLibravatar Eric Wong1-0/+2
Having non-existent packs in objects/info/packs causes dumb HTTP clients to abort. v2: use single loop with ALLOC_GROW as suggested by Jeff King Signed-off-by: Eric Wong <e@80x24.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28git-p4: allow unshelving of branched filesLibravatar Simon Williams1-1/+7
When unshelving a changelist, git-p4 tries to work out the appropriate parent commit in a given branch (default: HEAD). To do this, it looks at the state of any pre-existing files in the target Perforce branch, omitting files added in the shelved changelist. Currently, only files added (or move targets) are classed as new. However, files integrated from other branches (i.e. a 'branch' action) also need to be considered as added, for this purpose. Signed-off-by: Simon Williams <simon@no-dns-yet.org.uk> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28am: fix --interactive HEAD tree resolutionLibravatar Jeff King1-0/+52
In --interactive mode, "git am --resolved" will try to generate a patch based on what is in the index, so that it can prompt "apply this patch?". To do so it needs the tree of HEAD, which it tries to get with get_oid_tree(). However, this doesn't yield a tree object; the "tree" part just means "if you must disambiguate short oids, then prefer trees" (and we do not need to disambiguate at all, since we are feeding a ref). Instead, we must parse the oid as a commit (which should always be true in a non-corrupt repository), and access its tree pointer manually. This has been broken since the conversion to C in 7ff2683253 (builtin-am: implement -i/--interactive, 2015-08-04), but there was no test coverage because of interactive-mode's insistence on having a tty. That was lifted in the previous commit, so we can now add a test for this case. Note that before this patch, the test would result in a BUG() which comes from 3506dc9445 (has_uncommitted_changes(): fall back to empty tree, 2018-07-11). But before that, we'd have simply segfaulted (and in fact this is the exact type of case the BUG() added there was trying to catch!). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28trace2: rename environment variables to GIT_TRACE2*Libravatar SZEDER Gábor5-32/+32
For an environment variable that is supposed to be set by users, the GIT_TR2* env vars are just too unclear, inconsistent, and ugly. Most of the established GIT_* environment variables don't use abbreviations, and in case of the few that do (GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the abbreviations (DIR and OPTS) stand for. But what does TR stand for? Track, traditional, trailer, transaction, transfer, transformation, transition, translation, transplant, transport, traversal, tree, trigger, truncate, trust, or ...?! The trace2 facility, as the '2' suffix in its name suggests, is supposed to eventually supercede Git's original trace facility. It's reasonable to expect that the corresponding environment variables follow suit, and after the original GIT_TRACE variables they are called GIT_TRACE2; there is no such thing is 'GIT_TR'. All trace2-specific config variables are, very sensibly, in the 'trace2' section, not in 'tr2'. OTOH, we don't gain anything at all by omitting the last three characters of "trace" from the names of these environment variables. So let's rename all GIT_TR2* environment variables to GIT_TRACE2*, before they make their way into a stable release. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28upload-pack: strip namespace from symref dataLibravatar Jeff King1-0/+28
Since 7171d8c15f (upload-pack: send symbolic ref information as capability, 2013-09-17), we've sent cloning and fetching clients special information about which branch HEAD is pointing to, so that they don't have to guess based on matching up commit ids. However, this feature has never worked properly with the GIT_NAMESPACE feature. Because upload-pack uses head_ref_namespaced(find_symref), we do find and report on refs/namespaces/foo/HEAD instead of the actual HEAD of the repo. This makes sense, since the branch pointed to by the top-level HEAD may not be advertised at all. But we do two things wrong: 1. We report the full name refs/namespaces/foo/HEAD, instead of just HEAD. Meaning no client is going to bother doing anything with that symref, since we're not otherwise advertising it. 2. We report the symref destination using its full name (e.g., refs/namespaces/foo/refs/heads/master). That's similarly useless to the client, who only saw "refs/heads/master" in the advertisement. We should be stripping the namespace prefix off of both places (which this patch fixes). Likely nobody noticed because we tend to do the right thing anyway. Bug (1) means that we said nothing about HEAD (just refs/namespace/foo/HEAD). And so the client half of the code, from a45b5f0552 (connect: annotate refs with their symref information in get_remote_head(), 2013-09-17), does not annotate HEAD, and we use the fallback in guess_remote_head(), matching refs by object id. Which is usually right. It only falls down in ambiguous cases, like the one laid out in the included test. This also means that we don't have to worry about breaking anybody who was putting pre-stripped names into their namespace symrefs when we fix bug (2). Because of bug (1), nobody would have been using the symref we advertised in the first place (not to mention that those symrefs would have appeared broken for any non-namespaced access). Note that we have separate fixes here for the v0 and v2 protocols. The symref advertisement moved in v2 to be a part of the ls-refs command. This actually gets part (1) right, since the symref annotation piggy-backs on the existing ref advertisement, which is properly stripped. But it still needs a fix for part (2). The included tests cover both protocols. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>