summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
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-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-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-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>
2019-05-28clone: add `--remote-submodules` flagLibravatar Ben Avison1-0/+54
When using `git clone --recurse-submodules` there was previously no way to pass a `--remote` switch to the implicit `git submodule update` command for any use case where you want the submodules to be checked out on their remote-tracking branch rather than with the SHA-1 recorded in the superproject. This patch rectifies this situation. It actually passes `--no-fetch` to `git submodule update` as well on the grounds they the submodule has only just been cloned, so fetching from the remote again only serves to slow things down. Signed-off-by: Ben Avison <bavison@riscosopen.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'jk/get-oid-indexed-object-name'Libravatar Junio C Hamano1-6/+2
The codepath to parse :<path> that obtains the object name for an indexed object has been made more robust. * jk/get-oid-indexed-object-name: get_oid: handle NULL repo->index
2019-05-19Merge branch 'tz/test-lib-check-working-jgit'Libravatar Junio C Hamano1-1/+1
A prerequiste check in the test suite to see if a working jgit is available was made more robust. * tz/test-lib-check-working-jgit: test-lib: try harder to ensure a working jgit
2019-05-19Merge branch 'es/check-non-portable-pre-5.10'Libravatar Junio C Hamano1-4/+5
Developer support update. * es/check-non-portable-pre-5.10: check-non-portable-shell: support Perl versions older than 5.10
2019-05-19Merge branch 'js/fsmonitor-refresh-after-discarding-index'Libravatar Junio C Hamano2-1/+31
The fsmonitor interface got out of sync after the in-core index file gets discarded, which has been corrected. * js/fsmonitor-refresh-after-discarding-index: fsmonitor: force a refresh after the index was discarded fsmonitor: demonstrate that it is not refreshed after discard_index()
2019-05-19Merge branch 'js/t5580-unc-alternate-test'Libravatar Junio C Hamano1-0/+12
An additional test for MinGW * js/t5580-unc-alternate-test: t5580: verify that alternates can be UNC paths
2019-05-19Merge branch 'bl/t4253-exit-code-from-format-patch'Libravatar Junio C Hamano1-2/+4
Avoid patterns to pipe output from a git command to feed another command in tests. * bl/t4253-exit-code-from-format-patch: t4253-am-keep-cr-dos: avoid using pipes
2019-05-19Merge branch 'dl/difftool-mergetool'Libravatar Junio C Hamano2-61/+126
Update "git difftool" and "git mergetool" so that the combinations of {diff,merge}.{tool,guitool} configuration variables serve as fallback settings of each other in a sensible order. * dl/difftool-mergetool: difftool: fallback on merge.guitool difftool: make --gui, --tool and --extcmd mutually exclusive mergetool: fallback to tool when guitool unavailable mergetool--lib: create gui_mode function mergetool: use get_merge_tool function t7610: add mergetool --gui tests t7610: unsuppress output
2019-05-19Merge branch 'js/t6500-use-windows-pid-on-mingw'Libravatar Junio C Hamano1-1/+9
Future-proof a test against an update to MSYS2 runtime v3.x series. * js/t6500-use-windows-pid-on-mingw: t6500(mingw): use the Windows PID of the shell
2019-05-19Merge branch 'jk/apache-lsan'Libravatar Junio C Hamano1-0/+1
Allow tests that involve httpd to be run under leak sanitizer, just like we can already do so under address sanitizer. * jk/apache-lsan: t/lib-httpd: pass LSAN_OPTIONS through apache
2019-05-19Merge branch 'nd/parse-options-aliases'Libravatar Junio C Hamano2-0/+20
Attempt to use an abbreviated option in "git clone --recurs" is responded by a request to disambiguate between --recursive and --recurse-submodules, which is bad because these two are synonyms. The parse-options API has been extended to define such synonyms more easily and not produce an unnecessary failure. * nd/parse-options-aliases: parse-options: don't emit "ambiguous option" for aliases
2019-05-19Merge branch 'dl/branch-from-3dot-merge-base'Libravatar Junio C Hamano2-30/+40
"git branch new A...B" and "git checkout -b new A...B" have been taught that in their contexts, the notation A...B means "the merge base between these two commits", just like "git checkout A...B" detaches HEAD at that commit. * dl/branch-from-3dot-merge-base: branch: make create_branch accept a merge base rev t2018: cleanup in current test