summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-11-20commit-graph: split up close_reachable() progress outputLibravatar Ævar Arnfjörð Bjarmason1-3/+10
Amend the progress output added in 7b0f229222 ("commit-graph write: add progress output", 2018-09-17) so that the total numbers it reports aren't higher than the total number of commits anymore. See [1] for a bug report pointing that out. When I added this I wasn't intending to provide an accurate count, but just have some progress output to show the user the command wasn't hanging[2]. But since we are showing numbers, let's make them accurate. The progress descriptions were suggested by Derrick Stolee in [3]. As noted in [2] we are unlikely to show anything except the "Expanding reachable..." message even on fairly large repositories such as linux.git. On a test repository I have with north of 7 million commits all of these are displayed. Two of them don't show up for long, but as noted in [5] future-proofing this for if the loops become more expensive in the future makes sense. 1. https://public-inbox.org/git/20181010203738.GE23446@szeder.dev/ 2. https://public-inbox.org/git/87pnwhea8y.fsf@evledraar.gmail.com/ 3. https://public-inbox.org/git/f7a0cbee-863c-61d3-4959-5cec8b43c705@gmail.com/ 4. https://public-inbox.org/git/20181015160545.GG19800@szeder.dev/ 5. https://public-inbox.org/git/87murle8da.fsf@evledraar.gmail.com/ Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-20gc: fix regression in 7b0f229222 impacting --quietLibravatar Ævar Arnfjörð Bjarmason2-1/+22
Fix a regression in my recent 7b0f229222 ("commit-graph write: add progress output", 2018-09-17). The newly added progress output for "commit-graph write" didn't check the --quiet option. Do so, and add a test asserting that this works as expected. Since the TTY prequisite isn't available everywhere let's add a version of this that both requires and doesn't require that. This test might be overly specific and will break if new progress output is added, but I think it'll serve as a good reminder to test the undertested progress mode(s). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-17commit-graph verify: add progress outputLibravatar Ævar Arnfjörð Bjarmason1-0/+5
For the reasons explained in the "commit-graph write: add progress output" commit leading up to this one, emit progress on "commit-graph verify". Since e0fd51e1d7 ("fsck: verify commit-graph", 2018-06-27) "git fsck" has called this command if core.commitGraph=true, but there's been no progress output to indicate that anything was different. Now there is (on my tiny dotfiles.git repository): $ git -c core.commitGraph=true -C ~/ fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (2821/2821), done. dangling blob 5b8bbdb9b788ed90459f505b0934619c17cc605b Verifying commits in commit graph: 100% (867/867), done. And on a larger repository, such as the 2015-04-03-1M-git.git test repository: $ time git -c core.commitGraph=true -C ~/g/2015-04-03-1M-git/ commit-graph verify Verifying commits in commit graph: 100% (1000447/1000447), done. real 0m7.813s [...] Since the "commit-graph verify" subcommand is never called from "git gc", we don't have to worry about passing some some "report_progress" progress variable around for this codepath. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-17commit-graph write: add progress outputLibravatar Ævar Arnfjörð Bjarmason4-13/+60
Before this change the "commit-graph write" command didn't report any progress. On my machine this command takes more than 10 seconds to write the graph for linux.git, and around 1m30s on the 2015-04-03-1M-git.git[1] test repository (a test case for a large monorepository). Furthermore, since the gc.writeCommitGraph setting was added in d5d5d7b641 ("gc: automatically write commit-graph files", 2018-06-27), there was no indication at all from a "git gc" run that anything was different. This why one of the progress bars being added here uses start_progress() instead of start_delayed_progress(), so that it's guaranteed to be seen. E.g. on my tiny 867 commit dotfiles.git repository: $ git -c gc.writeCommitGraph=true gc Enumerating objects: 2821, done. [...] Computing commit graph generation numbers: 100% (867/867), done. On larger repositories, such as linux.git the delayed progress bar(s) will kick in, and we'll show what's going on instead of, as was previously happening, printing nothing while we write the graph: $ git -c gc.writeCommitGraph=true gc [...] Annotating commits in commit graph: 1565573, done. Computing commit graph generation numbers: 100% (782484/782484), done. Note that here we don't show "Finding commits for commit graph", this is because under "git gc" we seed the search with the commit references in the repository, and that set is too small to show any progress, but would e.g. on a smaller repo such as git.git with --stdin-commits: $ git rev-list --all | git -c gc.writeCommitGraph=true write --stdin-commits Finding commits for commit graph: 100% (162576/162576), done. Computing commit graph generation numbers: 100% (162576/162576), done. With --stdin-packs we don't show any estimation of how much is left to do. This is because we might be processing more than one pack. We could be less lazy here and show progress, either by detecting that we're only processing one pack, or by first looping over the packs to discover how many commits they have. I don't see the point in doing that work. So instead we get (on 2015-04-03-1M-git.git): $ echo pack-<HASH>.idx | git -c gc.writeCommitGraph=true --exec-path=$PWD commit-graph write --stdin-packs Finding commits for commit graph: 13064614, done. Annotating commits in commit graph: 3001341, done. Computing commit graph generation numbers: 100% (1000447/1000447), done. No GC mode uses --stdin-packs. It's what they use at Microsoft to manually compute the generation numbers for their collection of large packs which are never coalesced. The reason we need a "report_progress" variable passed down from "git gc" is so that we don't report this output when we're running in the process "git gc --auto" detaches from the terminal. Since we write the commit graph from the "git gc" process itself (as opposed to what we do with say the "git repack" phase), we'd end up writing the output to .git/gc.log and reporting it to the user next time as part of the "The last gc run reported the following[...]" error, see 329e6e8794 ("gc: save log from daemonized gc --auto and print it next time", 2015-09-19). So we must keep track of whether or not we're running in that demonized mode, and if so print no progress. See [2] and subsequent replies for a discussion of an approach not taken in compute_generation_numbers(). I.e. we're saying "Computing commit graph generation numbers", even though on an established history we're mostly skipping over all the work we did in the past. This is similar to the white lie we tell in the "Writing objects" phase (not all are objects being written). Always showing progress is considered more important than accuracy. I.e. on a repository like 2015-04-03-1M-git.git we'd hang for 6 seconds with no output on the second "git gc" if no changes were made to any objects in the interim if we'd take the approach in [2]. 1. https://github.com/avar/2015-04-03-1M-git 2. <c6960252-c095-fb2b-e0bc-b1e6bb261614@gmail.com> (https://public-inbox.org/git/c6960252-c095-fb2b-e0bc-b1e6bb261614@gmail.com/) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-10Git 2.19Libravatar Junio C Hamano2-9/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-10Merge tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano9-25222/+41448
l10n for Git 2.19.0 round 2 * tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.19.0 l10n round 1 to 2 l10n: bg.po: Updated Bulgarian translation (3958t) l10n: vi.po(3958t): updated Vietnamese translation v2.19.0 round 2 l10n: es.po v2.19.0 round 2 l10n: fr.po v2.19.0 rnd 2 l10n: fr.po v2.19.0 rnd 1 l10n: fr: fix a message seen in git bisect l10n: sv.po: Update Swedish translation (3958t0f0u) l10n: git.pot: v2.19.0 round 2 (3 new, 5 removed) l10n: ru.po: update Russian translation l10n: git.pot: v2.19.0 round 1 (382 new, 30 removed) l10n: de.po: translate 108 new messages l10n: zh_CN: review for git 2.18.0 l10n: sv.po: Update Swedish translation(3608t0f0u)
2018-09-10Merge branch 'jn/submodule-core-worktree-revert'Libravatar Junio C Hamano6-55/+2
* jn/submodule-core-worktree-revert: Revert "Merge branch 'sb/submodule-core-worktree'"
2018-09-10Merge branch 'mk/http-backend-content-length'Libravatar Junio C Hamano2-1/+12
The earlier attempt barfed when given a CONTENT_LENGTH that is set to an empty string. RFC 3875 is fairly clear that in this case we should not read any message body, but we've been reading through to the EOF in previous versions (which did not even pay attention to the environment variable), so keep that behaviour for now in this late update. * mk/http-backend-content-length: http-backend: allow empty CONTENT_LENGTH
2018-09-09l10n: zh_CN: for git v2.19.0 l10n round 1 to 2Libravatar Jiang Xin1-2821/+4584
Translate 382 new messages (3958t0f0u) for git 2.19.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2018-09-09Merge branch 'master' of git://github.com/alshopov/git-poLibravatar Jiang Xin1-2750/+4607
* 'master' of git://github.com/alshopov/git-po: l10n: bg.po: Updated Bulgarian translation (3958t)
2018-09-09l10n: bg.po: Updated Bulgarian translation (3958t)Libravatar Alexander Shopov1-2750/+4607
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2018-09-07Revert "Merge branch 'sb/submodule-core-worktree'"Libravatar Jonathan Nieder6-55/+2
This reverts commit 7e25437d35a70791b345872af202eabfb3e1a8bc, reversing changes made to 00624d608cc69bd62801c93e74d1ea7a7ddd6598. v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after update, 2018-06-18) assumes an "absorbed" submodule layout, where the submodule's Git directory is in the superproject's .git/modules/ directory and .git in the submodule worktree is a .git file pointing there. In particular, it uses $GIT_DIR/modules/$name to find the submodule to find out whether it already has core.worktree set, and it uses connect_work_tree_and_git_dir if not, resulting in fatal: could not open sub/.git for writing The context behind that patch: v2.19.0-rc0~165^2~2 (submodule: unset core.worktree if no working tree is present, 2018-06-12) unsets core.worktree when running commands like "git checkout --recurse-submodules" to switch to a branch without the submodule. If a user then uses "git checkout --no-recurse-submodules" to switch back to a branch with the submodule and runs "git submodule update", this patch is needed to ensure that commands using the submodule directly are aware of the path to the worktree. It is late in the release cycle, so revert the whole 3-patch series. We can try again later for 2.20. Reported-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-07http-backend: allow empty CONTENT_LENGTHLibravatar Max Kirillov2-1/+12
According to RFC3875, empty environment variable is equivalent to unset, and for CONTENT_LENGTH it should mean zero body to read. However, unset CONTENT_LENGTH is also used for chunked encoding to indicate reading until EOF. At least, the test "large fetch-pack requests can be split across POSTs" from t5551 starts faliing, if unset or empty CONTENT_LENGTH is treated as zero length body. So keep the existing behavior as much as possible. Add a test for the case. Reported-By: Jelmer Vernooij <jelmer@jelmer.uk> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-07l10n: vi.po(3958t): updated Vietnamese translation v2.19.0 round 2Libravatar Tran Ngoc Quan1-2800/+4576
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2018-09-06l10n: es.po v2.19.0 round 2Libravatar Christopher Diaz Riveros1-2753/+4571
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
2018-09-06Merge branch 'fr_2.19.0_rnd1' of git://github.com/jnavila/gitLibravatar Jiang Xin1-2786/+4588
* 'fr_2.19.0_rnd1' of git://github.com/jnavila/git: l10n: fr.po v2.19.0 rnd 2 l10n: fr.po v2.19.0 rnd 1 l10n: fr: fix a message seen in git bisect
2018-09-05l10n: fr.po v2.19.0 rnd 2Libravatar Jean-Noël Avila1-283/+328
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2018-09-05l10n: fr.po v2.19.0 rnd 1Libravatar Jean-Noël Avila1-2718/+4475
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2018-09-05l10n: fr: fix a message seen in git bisectLibravatar Raphaël Hertzog1-2/+2
"cette" can be only be used before a word (like in "cette bouteille" for "this bottle"), but here "this" refers to the current step and we have to use "ceci" in French. Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
2018-09-04l10n: sv.po: Update Swedish translation (3958t0f0u)Libravatar Peter Krefting1-2800/+4569
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2018-09-04Git 2.19-rc2Libravatar Junio C Hamano1-0/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Merge branch 'es/chain-lint-more'Libravatar Junio C Hamano5-4/+18
The test linter code has learned that the end of here-doc mark "EOF" can be quoted in a double-quote pair, not just in a single-quote pair. * es/chain-lint-more: chainlint: match "quoted" here-doc tags
2018-09-04Merge branch 'ab/portable-more'Libravatar Junio C Hamano10-44/+53
Portability fix. * ab/portable-more: tests: fix non-portable iconv invocation tests: fix non-portable "${var:-"str"}" construct tests: fix and add lint for non-portable grep --file tests: fix version-specific portability issue in Perl JSON tests: use shorter labels in chainlint.sed for AIX sed tests: fix comment syntax in chainlint.sed for AIX sed tests: fix and add lint for non-portable seq tests: fix and add lint for non-portable head -c N
2018-09-04Merge branch 'es/freebsd-iconv-portability'Libravatar Junio C Hamano1-1/+11
Build fix. * es/freebsd-iconv-portability: config.mak.uname: resolve FreeBSD iconv-related compilation warning
2018-09-04Merge branch 'ds/commit-graph-lockfile-fix'Libravatar Junio C Hamano1-1/+4
"git merge-base" in 2.19-rc1 has performance regression when the (experimental) commit-graph feature is in use, which has been mitigated. * ds/commit-graph-lockfile-fix: commit: don't use generation numbers if not needed
2018-09-04Merge branch 'en/directory-renames-nothanks'Libravatar Junio C Hamano4-6/+124
Recent addition of "directory rename" heuristics to the merge-recursive backend makes the command susceptible to false positives and false negatives. In the context of "git am -3", which does not know about surrounding unmodified paths and thus cannot inform the merge machinery about the full trees involved, this risk is particularly severe. As such, the heuristic is disabled for "git am -3" to keep the machinery "more stupid but predictable". * en/directory-renames-nothanks: am: avoid directory rename detection when calling recursive merge machinery merge-recursive: add ability to turn off directory rename detection t3401: add another directory rename testcase for rebase and am
2018-09-04Merge branch 'pw/rebase-i-author-script-fix'Libravatar Junio C Hamano2-12/+53
Recent "git rebase -i" update started to write bogusly formatted author-script, with a matching broken reading code. These are fixed. * pw/rebase-i-author-script-fix: sequencer: fix quoting in write_author_script sequencer: handle errors from read_author_ident()
2018-09-04l10n: git.pot: v2.19.0 round 2 (3 new, 5 removed)Libravatar Jiang Xin1-255/+247
Generate po/git.pot from v2.19.0-rc1 for git v2.19.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2018-09-04Merge branch 'master' of git://github.com/git-l10n/git-poLibravatar Jiang Xin5-8458/+13907
* 'master' of git://github.com/git-l10n/git-po: l10n: ru.po: update Russian translation l10n: git.pot: v2.19.0 round 1 (382 new, 30 removed) l10n: de.po: translate 108 new messages l10n: zh_CN: review for git 2.18.0 l10n: sv.po: Update Swedish translation(3608t0f0u)
2018-08-31config.mak.uname: resolve FreeBSD iconv-related compilation warningLibravatar Eric Sunshine1-1/+11
OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines it unconditionally. However, recent versions do not need it, and its presence results in compilation warnings. Resolve this issue by defining OLD_ICONV only for older FreeBSD versions. Specifically, revision r281550[1], which is part of FreeBSD 11, removed the need for OLD_ICONV, and r282275[2] back-ported that change to 10.2. Versions prior to 10.2 do need it. [1] https://github.com/freebsd/freebsd/commit/b0813ee288f64f677a2cebf7815754b027a8215b [2] https://github.com/freebsd/freebsd/commit/b709ec868adb5170d09bc5a66b18d0e0d5987ab6 [es: commit message; tweak version check to distinguish 10.x versions] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30commit: don't use generation numbers if not neededLibravatar Derrick Stolee1-1/+4
In 3afc679b "commit: use generations in paint_down_to_common()", the queue in paint_down_to_common() was changed to use a priority order based on generation number before commit date. This served two purposes: 1. When generation numbers are present, the walk guarantees correct topological relationships, regardless of clock skew in commit dates. 2. It enables short-circuiting the walk when the min_generation parameter is added in d7c1ec3e "commit: add short-circuit to paint_down_to_common()". This short-circuit helps commands like 'git branch --contains' from needing to walk to a merge base when we know the result is false. The commit message for 3afc679b includes the following sentence: This change does not affect the number of commits that are walked during the execution of paint_down_to_common(), only the order that those commits are inspected. This statement is incorrect. Because it changes the order in which the commits are inspected, it changes the order they are added to the queue, and hence can change the number of loops before the queue_has_nonstale() method returns true. This change makes a concrete difference depending on the topology of the commit graph. For instance, computing the merge-base between consecutive versions of the Linux kernel has no effect for versions after v4.9, but 'git merge-base v4.8 v4.9' presents a performance regression: v2.18.0: 0.122s v2.19.0-rc1: 0.547s HEAD: 0.127s To determine that this was simply an ordering issue, I inserted a counter within the while loop of paint_down_to_common() and found that the loop runs 167,468 times in v2.18.0 and 635,579 times in v2.19.0-rc1. The topology of this case can be described in a simplified way here: v4.9 | \ | \ v4.8 \ | \ \ | \ | ... A B | / / | / / |/__/ C Here, the "..." means "a very long line of commits". By generation number, A and B have generation one more than C. However, A and B have commit date higher than most of the commits reachable from v4.8. When the walk reaches v4.8, we realize that it has PARENT1 and PARENT2 flags, so everything it can reach is marked as STALE, including A. B has only the PARENT1 flag, so is not STALE. When paint_down_to_common() is run using compare_commits_by_commit_date, A and B are removed from the queue early and C is inserted into the queue. At this point, C and the rest of the queue entries are marked as STALE. The loop then terminates. When paint_down_to_common() is run using compare_commits_by_gen_then_commit_date, B is removed from the queue only after the many commits reachable from v4.8 are explored. This causes the loop to run longer. The reason for this regression is simple: the queue order is intended to not explore a commit until everything that _could_ reach that commit is explored. From the information gathered by the original ordering, we have no guarantee that there is not a commit D reachable from v4.8 that can also reach B. We gained absolute correctness in exchange for a performance regression. The performance regression is probably the worse option, since these incorrect results in paint_down_to_common() are rare. The topology required for the performance regression are less rare, but still require multiple merge commits where the parents differ greatly in generation number. In our example above, the commit A is as important as the commit B to demonstrate the problem, since otherwise the commit C will sit in the queue as non-stale just as long in both orders. The solution provided uses the min_generation parameter to decide if we should use generation numbers in our ordering. When min_generation is equal to zero, it means that the caller has no known cutoff for the walk, so we should rely on our commit-date heuristic as before; this is the case with merge_bases_many(). When min_generation is non-zero, then the caller knows a valuable cutoff for the short-circuit mechanism; this is the case with remove_redundant() and in_merge_bases_many(). Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30am: avoid directory rename detection when calling recursive merge machineryLibravatar Elijah Newren2-2/+3
Let's say you have the following three trees, where Base is from one commit behind either master or branch: Base : bar_v1, foo/{file1, file2, file3} branch: bar_v2, foo/{file1, file2}, goo/file3 master: bar_v3, foo/{file1, file2, file3} Using git-am (or am-based rebase) to apply the changes from branch onto master results in the following tree: Result: bar_merged, goo/{file1, file2, file3} This is not what users want; they did not rename foo/ -> goo/, they only renamed one file within that directory. The reason this happens is am constructs fake trees (via build_fake_ancestor()) of the following form: Base_bfa : bar_v1, foo/file3 branch_bfa: bar_v2, goo/file3 Combining these two trees with master's tree: master: bar_v3, foo/{file1, file2, file3}, You can see that merge_recursive_generic() would see branch_bfa as renaming foo/ -> goo/, and master as just adding both foo/file1 and foo/file2. As such, it ends up with goo/{file1, file2, file3} The core problem is that am does not have access to the original trees; it can only construct trees using the blobs involved in the patch. As such, it is not safe to perform directory rename detection within am -3. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30merge-recursive: add ability to turn off directory rename detectionLibravatar Elijah Newren2-5/+14
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30t3401: add another directory rename testcase for rebase and amLibravatar Elijah Newren1-1/+109
Similar to commit 16346883ab ("t3401: add directory rename testcases for rebase and am", 2018-06-27), add another testcase for directory rename detection. This new testcase differs in that it showcases a situation where no directory rename was performed, but which some backends incorrectly detect. As with the other testcase, run this in conjunction with each of the types of rebases: git-rebase--interactive git-rebase--am git-rebase--merge and also use the same testcase for git am --3way Reported-by: Nikolay Kasyanov <corrmage@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29chainlint: match "quoted" here-doc tagsLibravatar Eric Sunshine5-4/+18
A here-doc tag can be quoted ('EOF'/"EOF") or escaped (\EOF) to suppress interpolation within the body. chainlint recognizes single-quoted and escaped tags, but does not know about double-quoted tags. For completeness, teach it to recognize double-quoted tags, as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29tests: fix non-portable iconv invocationLibravatar Ævar Arnfjörð Bjarmason1-1/+5
The iconv that comes with a FreeBSD 11.2-RELEASE-p2 box I have access to doesn't support the SHIFT-JIS encoding. Guard a test added in e92d62253 ("convert: add round trip check based on 'core.checkRoundtripEncoding'", 2018-04-15) first released with Git v2.18.0 with a prerequisite that checks for its availability. The iconv command is in POSIX, and we have numerous tests unconditionally relying on its ability to convert ASCII, UTF-8 and UTF-16, but unconditionally relying on the presence of more obscure encodings isn't portable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29tests: fix non-portable "${var:-"str"}" constructLibravatar Ævar Arnfjörð Bjarmason1-1/+1
On both AIX 7200-00-01-1543 and FreeBSD 11.2-RELEASE-p2 the "${var:-"str"}" syntax means something different than what it does under the bash or dash shells. Both will consider the start of the new unescaped quotes to be a new argument to test_expect_success, resulting in the following error: error: bug in the test script: 'git diff-tree initial # magic is (not' does not look like a prereq Fix this by removing the redundant quotes. There's no need for them, and the resulting code works under all the aforementioned shells. This fixes a regression in c2f1d3989 ("t4013: test new output from diff --abbrev --raw", 2017-12-03) first released with Git v2.16.0. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28Git 2.19-rc1Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28l10n: ru.po: update Russian translationLibravatar Dimitriy Ryazantcev1-3496/+6652
Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com>
2018-08-27Getting ready for -rc1Libravatar Junio C Hamano1-1/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'ja/i18n-message-fixes'Libravatar Junio C Hamano3-3/+3
Messages fix. * ja/i18n-message-fixes: i18n: fix mistakes in translated strings
2018-08-27Merge branch 'ds/commit-graph-fsck'Libravatar Junio C Hamano1-6/+11
Finishing touches to doc. * ds/commit-graph-fsck: config: fix commit-graph related config docs
2018-08-27Merge branch 'js/range-diff'Libravatar Junio C Hamano1-1/+1
Finishing touched to help string. * js/range-diff: range-diff: update stale summary of --no-dual-color
2018-08-27Merge branch 'sg/test-rebase-editor-fix'Libravatar Junio C Hamano1-3/+3
Test fix. * sg/test-rebase-editor-fix: t/lib-rebase.sh: support explicit 'pick' commands in 'fake_editor.sh'
2018-08-27Merge branch 'jk/hashcmp-optim-for-2.19'Libravatar Junio C Hamano1-0/+10
Partially revert the support for multiple hash functions to regain hash comparison performance; we'd think of a way to do this better in the next cycle. * jk/hashcmp-optim-for-2.19: hashcmp: assert constant hash size
2018-08-27Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-1/+1
Test fixes. * ab/test-must-be-empty-for-master: t6018-rev-list-glob: fix 'empty stdin' test
2018-08-27Merge branch 'sg/t3420-autostash-fix'Libravatar Junio C Hamano1-4/+4
Test fixes. * sg/t3420-autostash-fix: t3420-rebase-autostash: don't try to grep non-existing files
2018-08-27Merge branch 'sg/t3903-missing-fix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t3903-missing-fix: t3903-stash: don't try to grep non-existing file
2018-08-27Merge branch 'sg/t7501-thinkofix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t7501-thinkofix: t7501-commit: drop silly command substitution
2018-08-27Merge branch 'sg/t0020-conversion-fix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t0020-conversion-fix: t0020-crlf: check the right file