summaryrefslogtreecommitdiffstats
path: root/git-quiltimport.sh (unfollow)
Commit message (Collapse)AuthorFilesLines
2019-06-07l10n: fr.po: Review French translationCédric Malard1-15/+15
Signed-off-by: Cédric Malard <c.malard-git@valdun.net> Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
2019-06-06l10n: de.po: Update German translationMatthias Rüster1-3074/+4139
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2019-06-06l10n: de.po: improve description of 'git reset --quiet'Ralf Thielow1-1/+1
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2019-06-05l10n: TEAMS: Change German translation team leaderMatthias Rüster1-3/+3
Acked-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2019-06-05merge-recursive: restore accidentally dropped setting of pathElijah Newren2-0/+117
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-05l10n: bg.po: Updated Bulgarian translation (4581t)Alexander Shopov1-7/+11
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-06-05l10n: zh_CN: Revision for git v2.22.0 l10nFangyi Zhou2-54/+54
Revise 51 translations, improving consistency for some phrased. Update email address for Fangyi Zhou Signed-off-by: Fangyi Zhou <me@fangyi.io> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-06-05l10n: zh_CN: for git v2.22.0 l10n round 1~3Jiang Xin1-3040/+4015
Translate 274 new messages (4581t0f0u) for git 2.22.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-06-05l10n: es: 2.22.0 round 3Christopher Diaz Riveros1-8/+12
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
2019-06-04l10n: it.po: Updated Italian translationAlessandro Menti1-4745/+6015
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
2019-06-04l10n: fr v2.22.0 rnd 3Jean-Noël Avila1-10/+16
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-06-04l10n: vi.po(4581t): Updated Vietnamese translation for v2.22.0 round 3Tran Ngoc Quan1-12/+16
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2019-06-04l10n: git.pot: v2.22.0 round 3 (3 new, 2 removed)Jiang Xin1-6/+10
Generate po/git.pot from v2.22.0-rc3 for git v2.22.0 l10n round 3. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-06-03Git 2.22-rc3v2.22.0-rc3Junio C Hamano2-1/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-03i18n: fix typos found during l10n for git 2.22.0Jiang Xin2-3/+3
Fix two typos introduced by the following commits: + 31fba9d3b4 (diff-parseopt: convert --[src|dst]-prefix, 2019-03-24) + ed8b4132c8 (remote-curl: mark all error messages for translation, 2019-03-05) Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-03RelNotes: minor typo fixes in 2.22.0 draftTodd Zullinger1-6/+6
Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-03l10n: es: 2.22.0 round 2Christopher Diaz Riveros1-381/+394
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
2019-06-02l10n: bg.po: Updated Bulgarian translation (4580t)Alexander Shopov1-1577/+1590
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-06-01l10n: vi.po(4580t): Updated Vietnamese translation for v2.22.0 round 2Tran Ngoc Quan1-383/+396
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2019-05-31l10n: fr.po v2.22.0 round 2Jean-Noël Avila1-434/+537
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-05-31l10n: git.pot: v2.22.0 round 2 (6 new, 3 removed)Jiang Xin1-378/+391
Generate po/git.pot from v2.22.0-rc2 for git v2.22.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-05-30Git 2.22-rc2v2.22.0-rc2Junio C Hamano2-1/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-29list-objects-filter: disable 'sparse:path' filtersChristian Couder7-116/+37
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-29parse-options: check empty value in OPT_INTEGER and OPT_ABBREVNguyễn Thái Ngọc Duy2-0/+6
When parsing the argument for OPT_INTEGER and OPT_ABBREV, we check if we can parse the entire argument to a number with "if (*s)". There is one missing check: if "arg" is empty to begin with, we fail to notice. This could happen with long option by writing like git diff --inter-hunk-context= blah blah Before 16ed6c97cc (diff-parseopt: convert --inter-hunk-context, 2019-03-24), --inter-hunk-context is handled by a custom parser opt_arg() and does detect this correctly. This restores the bahvior for --inter-hunk-context and make sure all other integer options are handled the same (sane) way. For OPT_ABBREV this is new behavior. But it makes it consistent with the rest. PS. OPT_MAGNITUDE has similar code but git_parse_ulong() does detect empty "arg". So it's good to go. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-29diff-parseopt: restore -U (no argument) behaviorNguyễn Thái Ngọc Duy5-4/+100
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-29diff-parseopt: correct variable types that are used by parseoptNguyễn Thái Ngọc Duy1-1/+1
Most number-related OPT_ macros store the value in an 'int' variable. Many of the variables in 'struct diff_options' have a different type, but during the conversion to using parse_options() I failed to notice and correct. The problem was reported on s360x which is a big-endian architechture. The variable to store '-w' option in this case is xdl_opts, 'long' type, 8 bytes. But since parse_options() assumes 'int' (4 bytes), it will store bits in the wrong part of xdl_opts. The problem was found on little-endian platforms because parse_options() will accidentally store at the right part of xdl_opts. There aren't much to say about the type change (except that 'int' for xdl_opts should still be big enough, since Windows' long is the same size as 'int' and nobody has complained so far). Some safety checks may be implemented in the future to prevent class of bugs. Reported-by: Todd Zullinger <tmz@pobox.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-29l10n: bg.po: Updated Bulgarian translation (4577t)Alexander Shopov1-3137/+4156
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-05-28rebase docs: recommend `-r` over `-p`Johannes Schindelin1-2/+3
The `--preserve-merges` option is now deprecated in favor of `--rebase-merges`; Let's stop recommending the former. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28docs: say that `--rebase=preserve` is deprecatedJohannes Schindelin1-2/+3
As of Git v2.22.0, the `--preserve-merges` backend of `git rebase` will be officially deprecated in favor of the `--rebase-merges` backend. Consequently, `git pull --rebase=preserve` will also be deprected. State this explicitly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28tests: mark a couple more test cases as requiring `rebase -p`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-28fetch-pack: send server options after commandJonathan Tan1-1/+1
Currently, if any server options are specified during a protocol v2 fetch, server options will be sent before "command=fetch". Write server options to the request buffer in send_fetch_request() so that the components of the request are sent in the correct order. The protocol documentation states that the command must come first. The Git server implementation in serve.c (see process_request() in that file) tolerates any order of command and capability, which is perhaps why we haven't noticed this. This was noticed when testing against a JGit server implementation, which follows the documentation in this regard. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28trace2: fix tracing when NO_PTHREADS is definedJeff Hostetler1-3/+9
Teach trace2 TLS code to not rely on pthread_getspecific() when NO_PTHREADS is defined. Instead, always assume the context data of the main thread. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28rebase: replace incorrect logical negation by correct bitwise oneJohannes Schindelin1-1/+1
In bff014dac7d9 (builtin rebase: support the `verbose` and `diffstat` options, 2018-09-04), we added a line that wanted to remove the `REBASE_DIFFSTAT` bit from the flags, but it used an incorrect negation. Found by Coverity. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28progress: avoid empty line when breaking the progress lineSZEDER Gábor1-1/+1
Since commit 545dc345eb (progress: break too long progress bar lines, 2019-04-12) when splitting a too long progress line, sometimes it looks as if a superfluous empty line were added between the title line and the counters. To make sure that the previously displayed progress line is completely covered up when writing the new, shorter title line, we calculate how many characters need to be overwritten with spaces. Alas, this calculation doesn't account for the newline character at the end of the new title line, and resulted in printing one more space than strictly necessary. This extra space character doesn't matter, if the length of the previous progress line was shorter than the width of the terminal. However, if the previous line matched the terminal width, then this extra space made the new line longer, effectively adding that empty line after the title line. Fix this off-by-one to avoid that spurious empty line. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28trace2: document the supported values of GIT_TRACE2* env variablesSZEDER Gábor1-8/+35
The descriptions of the GIT_TRACE2* environment variables link to the technical docs for further details on the supported values. However, a link like this only really works if the docs are viewed in a browser and the full documentation is available. OTOH, in 'man git' there are no links to conveniently click on, and distro-shipped git packages tend to include only the man pages, while the technical docs and the docs in html format are in a separate 'git-doc' package. So let's describe the supported values to make the manpage more self-contained, but still keep the references to the technical docs because the details of the SID, and the JSON and perf output formats are definitely beyond the scope of 'man git'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28trace2: rename environment variables to GIT_TRACE2*SZEDER Gábor13-85/+85
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-28gitsubmodules: align html and nroff listsEmily Shaffer1-7/+7
There appears to be a bug in the toolchain generating manpages from lettered lists. When a list is enumerated with letters, the resulting nroff shows numbers instead. Mostly this is harmless, but in the case of gitsubmodules, the paragraph following the list refers back to each bullet by letter. As a result, reading this documentation via `man gitsubmodules` is hard to parse - readers must infer that a bug exists and a refers to 1, b refers to 2, and c refers to 3 in the list above. The problem specifically was introduced in ad47194; previously rather than generating numerated lists the bulleted area was entirely monospaced in HTML and shown in plaintext in nroff. The bug seems to exist in docbook-xml - I've reported it on May 1 via the docbook-apps mail list - but for now it may make more sense to just work around the issue. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28l10n: es: 2.22.0 round 1Christopher Diaz Riveros1-3065/+4150
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
2019-05-19Git 2.22-rc1v2.22.0-rc1Junio C Hamano2-1/+77
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19diff: fix mistake in translatable stringsJean-Noël Avila1-2/+2
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19l10n: vi.po(4577t): Updated Vietnamese translation for v2.22.0 round 1Tran Ngoc Quan1-3069/+4154
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2019-05-17l10n: fr.po v2.22.0.rnd1Jean-Noël Avila1-3065/+3998
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-05-16pkt-line: drop 'const'-ness of a param to set_packet_header()Junio C Hamano1-1/+1
The function's definition has a paramter of type "int" qualified as "const". The fact that the incoming parameter is used as read-only in the fuction is an implementation detail that the callers should not have to be told in the prototype declaring it (and "const" there has no effect, as C passes parameters by value). The prototype defined for the function in pkt-line.h lacked the matching "const" for this reason, but apparently some compilers (e.g. MS Visual C 2017) complain about the parameter type mismatch. Let's squelch it by removing the "const" that is pointless in the definition of a small and trivial function like this, which would not help optimizing compilers nor reading humans that much. Noticed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15test-lib: try harder to ensure a working jgitTodd Zullinger1-1/+1
The JGIT prereq uses `type jgit` to determine whether jgit is present. While this is usually sufficient, it won't help if the jgit found is badly broken. This wastes time running tests which fail due to no fault of our own. Use `jgit --version` instead, to guard against cases where jgit is present on the system, but will fail to run, e.g. because of some JRE issue, or missing Java dependencies. Checking that it gets far enough to process the '--version' argument isn't perfect, but seems to be good enough in practice. It's also consistent with how we detect some other dependencies, see e.g. the CURL and UNZIP prerequisites. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15get_oid: handle NULL repo->indexJeff King2-7/+3
When get_oid() and its helpers see an index name like ":.gitmodules", they try to load the index on demand, like: if (repo->index->cache) repo_read_index(repo); However, that misses the case when "repo->index" itself is NULL; we'll segfault in the conditional. This never happens with the_repository; there we always point its index field to &the_index. But a submodule repository may have a NULL index field until somebody calls repo_read_index(). This bug is triggered by t7411, but it was hard to notice because it's in an expect_failure block. That test was added by 2b1257e463 (t/helper: add test-submodule-nested-repo-config, 2018-10-25). Back then we had no easy way to access the .gitmodules blob of a submodule repo, so we expected (and got) an error message to that effect. Later, d9b8b8f896 (submodule-config.c: use repo_get_oid for reading .gitmodules, 2019-04-16) started looking in the correct repo, which is when we started triggering the segfault. With this fix, the test starts passing (once we clean it up as its comment instructs). Note that as far as I know, this bug could not be triggered outside of the test suite. It requires resolving an index name in a submodule, and all of the code paths (aside from test-tool) which do that either load the index themselves, or always pass the_repository. Ultimately it comes from 3a7a698e93 (sha1-name.c: remove implicit dependency on the_index, 2019-01-12), which replaced a check of "the_index.cache" with "repo->index->cache". So even if there is another way to trigger it, it wouldn't affect any versions before then. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15http-push: prevent format overflow warning with gcc >= 9Carlo Marcelo Arenas Belón1-2/+2
In function 'finish_request', inlined from 'process_response' at http-push.c:248:2: http-push.c:587:4: warning: '%s' directive argument is null [-Wformat-overflow=] 587 | fprintf(stderr, "Unable to get pack file %s\n%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 588 | request->url, curl_errorstr); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ request->url is needed for the error message if there was a failure during fetch but was being cleared unnecessarily earlier. note that the leak is prevented by calling release_request unconditionally at the end. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Suggested-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15stash: document stash.useBuiltinJohannes Schindelin1-0/+15
The stash.useBuiltin variable introduced in 90a462725e ("stash: optionally use the scripted version again", 2019-02-25) was turned on by default, but had no documentation. Let's document it so that users who run into any stability issues with the C rewrite know there's an escape hatch, and spell out that the user should please report the bug when they have to turn off the built-in stash. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-14l10n: sv.po: Update Swedish translation (4577t0f0u)Peter Krefting1-3073/+4140
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2019-05-14l10n: sv.po: Update Swedish translationPeter Krefting1-7/+7
Fix mistakes reported by Mattias Engdegård <mattiase@acm.org>. Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2019-05-14l10n: git.pot: v2.22.0 round 1 (270 new, 56 removed)Jiang Xin1-2987/+3927
Generate po/git.pot from v2.22.0-rc0 for git v2.22.0 l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>