Skip to main content

Browse the archive

https://github.com/git/git
31 May 2024, 23:06:24 UTC
sort by:
Revision Author Date Message Commit Date
cae598d Junio C Hamano 27 September 2018, 18:52:33 UTC Git 2.19.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:52:33 UTC
1958ad5 Junio C Hamano 27 September 2018, 18:50:45 UTC Sync with 2.18.1 * maint-2.18: Git 2.18.1 Git 2.17.2 fsck: detect submodule paths starting with dash fsck: detect submodule urls starting with dash Git 2.16.5 Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options 27 September 2018, 18:50:45 UTC
268fbcd Junio C Hamano 27 September 2018, 18:48:19 UTC Git 2.18.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:48:19 UTC
44f87da Junio C Hamano 27 September 2018, 18:45:01 UTC Sync with 2.17.2 * maint-2.17: Git 2.17.2 fsck: detect submodule paths starting with dash fsck: detect submodule urls starting with dash Git 2.16.5 Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options 27 September 2018, 18:45:01 UTC
6e9e91e Junio C Hamano 27 September 2018, 18:44:07 UTC Git 2.17.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:44:07 UTC
1a7fd1f Jeff King 24 September 2018, 08:42:19 UTC fsck: detect submodule paths starting with dash As with urls, submodule paths with dashes are ignored by git, but may end up confusing older versions. Detecting them via fsck lets us prevent modern versions of git from being a vector to spread broken .gitmodules to older versions. Compared to blocking leading-dash urls, though, this detection may be less of a good idea: 1. While such paths provide confusing and broken results, they don't seem to actually work as option injections against anything except "cd". In particular, the submodule code seems to canonicalize to an absolute path before running "git clone" (so it passes /your/clone/-sub). 2. It's more likely that we may one day make such names actually work correctly. Even after we revert this fsck check, it will continue to be a hassle until hosting servers are all updated. On the other hand, it's not entirely clear that the behavior in older versions is safe. And if we do want to eventually allow this, we may end up doing so with a special syntax anyway (e.g., writing "./-sub" in the .gitmodules file, and teaching the submodule code to canonicalize it when comparing). So on balance, this is probably a good protection. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:41:31 UTC
a124133 Jeff King 24 September 2018, 08:37:17 UTC fsck: detect submodule urls starting with dash Urls with leading dashes can cause mischief on older versions of Git. We should detect them so that they can be rejected by receive.fsckObjects, preventing modern versions of git from being a vector by which attacks can spread. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:41:26 UTC
e43aab7 Junio C Hamano 27 September 2018, 18:41:02 UTC Sync with 2.16.5 * maint-2.16: Git 2.16.5 Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options 27 September 2018, 18:41:02 UTC
27d05d1 Junio C Hamano 27 September 2018, 18:38:32 UTC Git 2.16.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:38:32 UTC
424aac6 Junio C Hamano 27 September 2018, 18:35:43 UTC Sync with 2.15.3 * maint-2.15: Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options 27 September 2018, 18:35:43 UTC
924c623 Junio C Hamano 27 September 2018, 18:33:47 UTC Git 2.15.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:33:47 UTC
902df9f Junio C Hamano 27 September 2018, 18:20:22 UTC Sync with Git 2.14.4 * maint-2.14: Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options 27 September 2018, 18:20:22 UTC
d0832b2 Junio C Hamano 27 September 2018, 18:19:11 UTC Git 2.14.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:19:11 UTC
273c614 Jeff King 24 September 2018, 08:39:55 UTC submodule-config: ban submodule paths that start with a dash We recently banned submodule urls that look like command-line options. This is the matching change to ban leading-dash paths. As with the urls, this should not break any use cases that currently work. Even with our "--" separator passed to git-clone, git-submodule.sh gets confused. Without the code portion of this patch, the clone of "-sub" added in t7417 would yield results like: /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s Fetched in submodule path '-sub', but it did not contain b56243f8f4eb91b2f1f8109452e659f14dd3fbe4. Direct fetching of that commit failed. Moreover, naively adding such a submodule doesn't work: $ git submodule add $url -sub The following path is ignored by one of your .gitignore files: -sub even though there is no such ignore pattern (the test script hacks around this with a well-placed "git mv"). Unlike leading-dash urls, though, it's possible that such a path _could_ be useful if we eventually made it work. So this commit should be seen not as recommending a particular policy, but rather temporarily closing off a broken and possibly dangerous code-path. We may revisit this decision later. There are two minor differences to the tests in t7416 (that covered urls): 1. We don't have a "./-sub" escape hatch to make this work, since the submodule code expects to be able to match canonical index names to the path field (so you are free to add submodule config with that path, but we would never actually use it, since an index entry would never start with "./"). 2. After this patch, cloning actually succeeds. Since we ignore the submodule.*.path value, we fail to find a config stanza for our submodule at all, and simply treat it as inactive. We still check for the "ignoring" message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 16:34:59 UTC
f6adec4 Jeff King 24 September 2018, 08:36:30 UTC submodule-config: ban submodule urls that start with dash The previous commit taught the submodule code to invoke our "git clone $url $path" with a "--" separator so that we aren't confused by urls or paths that start with dashes. However, that's just one code path. It's not clear if there are others, and it would be an easy mistake to add one in the future. Moreover, even with the fix in the previous commit, it's quite hard to actually do anything useful with such an entry. Any url starting with a dash must fall into one of three categories: - it's meant as a file url, like "-path". But then any clone is not going to have the matching path, since it's by definition relative inside the newly created clone. If you spell it as "./-path", the submodule code sees the "/" and translates this to an absolute path, so it at least works (assuming the receiver has the same filesystem layout as you). But that trick does not apply for a bare "-path". - it's meant as an ssh url, like "-host:path". But this already doesn't work, as we explicitly disallow ssh hostnames that begin with a dash (to avoid option injection against ssh). - it's a remote-helper scheme, like "-scheme::data". This _could_ work if the receiver bends over backwards and creates a funny-named helper like "git-remote--scheme". But normally there would not be any helper that matches. Since such a url does not work today and is not likely to do anything useful in the future, let's simply disallow them entirely. That protects the existing "git clone" path (in a belt-and-suspenders way), along with any others that might exist. Our tests cover two cases: 1. A file url with "./" continues to work, showing that there's an escape hatch for people with truly silly repo names. 2. A url starting with "-" is rejected. Note that we expect case (2) to fail, but it would have done so even without this commit, for the reasons given above. So instead of just expecting failure, let's also check for the magic word "ignoring" on stderr. That lets us know that we failed for the right reason. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 16:34:58 UTC
98afac7 Jeff King 24 September 2018, 08:32:15 UTC submodule--helper: use "--" to signal end of clone options When we clone a submodule, we call "git clone $url $path". But there's nothing to say that those components can't begin with a dash themselves, confusing git-clone into thinking they're options. Let's pass "--" to make it clear what we expect. There's no test here, because it's actually quite hard to make these names work, even with "git clone" parsing them correctly. And we're going to restrict these cases even further in future commits. So we'll leave off testing until then; this is just the minimal fix to prevent us from doing something stupid with a badly formed entry. Reported-by: joernchen <joernchen@phenoelit.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 16:34:55 UTC
1d4361b Junio C Hamano 10 September 2018, 17:41:56 UTC Git 2.19 Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 September 2018, 17:41:56 UTC
46d9a28 Junio C Hamano 10 September 2018, 17:41:11 UTC Merge tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po 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) 10 September 2018, 17:41:11 UTC
f38a45b Junio C Hamano 10 September 2018, 17:38:58 UTC Merge branch 'jn/submodule-core-worktree-revert' * jn/submodule-core-worktree-revert: Revert "Merge branch 'sb/submodule-core-worktree'" 10 September 2018, 17:38:58 UTC
fe468ef Junio C Hamano 10 September 2018, 17:29:16 UTC Merge branch 'mk/http-backend-content-length' 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 10 September 2018, 17:35:42 UTC
c1ac525 Jiang Xin 21 August 2018, 00:40:05 UTC l10n: zh_CN: for git v2.19.0 l10n round 1 to 2 Translate 382 new messages (3958t0f0u) for git 2.19.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 09 September 2018, 14:38:39 UTC
282c393 Jiang Xin 09 September 2018, 11:05:41 UTC Merge branch 'master' of git://github.com/alshopov/git-po * 'master' of git://github.com/alshopov/git-po: l10n: bg.po: Updated Bulgarian translation (3958t) 09 September 2018, 11:05:41 UTC
1eaabd4 Alexander Shopov 09 August 2018, 15:04:10 UTC l10n: bg.po: Updated Bulgarian translation (3958t) Signed-off-by: Alexander Shopov <ash@kambanaria.org> 09 September 2018, 09:29:19 UTC
f178c13 Jonathan Nieder 08 September 2018, 00:09:46 UTC Revert "Merge branch 'sb/submodule-core-worktree'" 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> 08 September 2018, 02:05:20 UTC
574c513 Max Kirillov 07 September 2018, 03:36:07 UTC http-backend: allow empty CONTENT_LENGTH 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> 07 September 2018, 19:35:51 UTC
7c73a6b Tran Ngoc Quan 07 September 2018, 06:41:08 UTC l10n: vi.po(3958t): updated Vietnamese translation v2.19.0 round 2 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> 07 September 2018, 06:41:08 UTC
33b7279 Christopher Diaz Riveros 06 September 2018, 09:27:56 UTC l10n: es.po v2.19.0 round 2 Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org> 06 September 2018, 09:27:56 UTC
f1627fa Jiang Xin 06 September 2018, 01:17:55 UTC Merge branch 'fr_2.19.0_rnd1' of git://github.com/jnavila/git * '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 06 September 2018, 01:17:55 UTC
2104663 Jean-Noël Avila 05 September 2018, 20:19:13 UTC l10n: fr.po v2.19.0 rnd 2 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> 05 September 2018, 20:19:48 UTC
0859ed6 Jean-Noël Avila 23 August 2018, 20:50:52 UTC l10n: fr.po v2.19.0 rnd 1 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> 05 September 2018, 20:15:09 UTC
8944a83 Raphaël Hertzog 04 July 2018, 15:43:56 UTC l10n: fr: fix a message seen in git bisect "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> 05 September 2018, 20:15:09 UTC
bc25f7a Peter Krefting 04 September 2018, 21:34:09 UTC l10n: sv.po: Update Swedish translation (3958t0f0u) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> 04 September 2018, 21:34:09 UTC
c05048d Junio C Hamano 04 September 2018, 21:33:27 UTC Git 2.19-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2018, 21:33:27 UTC
e9983f8 Junio C Hamano 04 September 2018, 21:31:40 UTC Merge branch 'es/chain-lint-more' 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 04 September 2018, 21:31:40 UTC
28d294a Junio C Hamano 04 September 2018, 21:31:40 UTC Merge branch 'ab/portable-more' 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 04 September 2018, 21:31:40 UTC
b571c25 Junio C Hamano 04 September 2018, 21:31:39 UTC Merge branch 'es/freebsd-iconv-portability' Build fix. * es/freebsd-iconv-portability: config.mak.uname: resolve FreeBSD iconv-related compilation warning 04 September 2018, 21:31:39 UTC
0a866db Junio C Hamano 04 September 2018, 21:31:39 UTC Merge branch 'ds/commit-graph-lockfile-fix' "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 04 September 2018, 21:31:39 UTC
ca676b9 Junio C Hamano 04 September 2018, 21:31:38 UTC Merge branch 'en/directory-renames-nothanks' 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 04 September 2018, 21:31:38 UTC
064e0b2 Junio C Hamano 04 September 2018, 21:31:38 UTC Merge branch 'pw/rebase-i-author-script-fix' 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() 04 September 2018, 21:31:38 UTC
98ac781 Jiang Xin 04 September 2018, 00:51:58 UTC l10n: git.pot: v2.19.0 round 2 (3 new, 5 removed) 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> 04 September 2018, 00:51:58 UTC
fb996aa Jiang Xin 04 September 2018, 00:49:54 UTC Merge branch 'master' of git://github.com/git-l10n/git-po * '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) 04 September 2018, 00:49:54 UTC
6c6ce21 Eric Sunshine 31 August 2018, 08:33:42 UTC config.mak.uname: resolve FreeBSD iconv-related compilation warning 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> 31 August 2018, 19:05:24 UTC
091f4cf Derrick Stolee 30 August 2018, 12:58:09 UTC commit: don't use generation numbers if not needed 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> 30 August 2018, 18:17:57 UTC
6aba117 Elijah Newren 29 August 2018, 07:06:13 UTC am: avoid directory rename detection when calling recursive merge machinery 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> 30 August 2018, 14:58:59 UTC
5fdddd9 Elijah Newren 29 August 2018, 07:06:12 UTC merge-recursive: add ability to turn off directory rename detection Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 August 2018, 14:58:59 UTC
e7588c9 Elijah Newren 29 August 2018, 07:06:11 UTC t3401: add another directory rename testcase for rebase and am 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> 30 August 2018, 14:58:59 UTC
3042b6b Eric Sunshine 29 August 2018, 09:45:32 UTC chainlint: match "quoted" here-doc tags 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> 29 August 2018, 17:57:38 UTC
f6af6f9 Ævar Arnfjörð Bjarmason 28 August 2018, 19:38:27 UTC tests: fix non-portable iconv invocation 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> 29 August 2018, 17:35:05 UTC
de231e5 Ævar Arnfjörð Bjarmason 28 August 2018, 19:38:26 UTC tests: fix non-portable "${var:-"str"}" construct 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> 29 August 2018, 17:34:10 UTC
2f74393 Junio C Hamano 28 August 2018, 19:01:01 UTC Git 2.19-rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2018, 19:01:01 UTC
a123a47 Dimitriy Ryazantcev 28 August 2018, 15:43:15 UTC l10n: ru.po: update Russian translation Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com> 28 August 2018, 15:58:36 UTC
b9dfa23 Junio C Hamano 27 August 2018, 21:34:54 UTC Getting ready for -rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 21:34:54 UTC
8edb1b3 Junio C Hamano 27 August 2018, 21:33:52 UTC Merge branch 'ja/i18n-message-fixes' Messages fix. * ja/i18n-message-fixes: i18n: fix mistakes in translated strings 27 August 2018, 21:33:52 UTC
aa5dc61 Junio C Hamano 27 August 2018, 21:33:51 UTC Merge branch 'ds/commit-graph-fsck' Finishing touches to doc. * ds/commit-graph-fsck: config: fix commit-graph related config docs 27 August 2018, 21:33:51 UTC
6201d75 Junio C Hamano 27 August 2018, 21:33:51 UTC Merge branch 'js/range-diff' Finishing touched to help string. * js/range-diff: range-diff: update stale summary of --no-dual-color 27 August 2018, 21:33:51 UTC
926107d Junio C Hamano 27 August 2018, 21:33:50 UTC Merge branch 'sg/test-rebase-editor-fix' Test fix. * sg/test-rebase-editor-fix: t/lib-rebase.sh: support explicit 'pick' commands in 'fake_editor.sh' 27 August 2018, 21:33:50 UTC
86ef236 Junio C Hamano 27 August 2018, 21:33:50 UTC Merge branch 'jk/hashcmp-optim-for-2.19' 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 27 August 2018, 21:33:50 UTC
99fb11d Junio C Hamano 27 August 2018, 21:33:49 UTC Merge branch 'ab/test-must-be-empty-for-master' Test fixes. * ab/test-must-be-empty-for-master: t6018-rev-list-glob: fix 'empty stdin' test 27 August 2018, 21:33:49 UTC
56ce87d Junio C Hamano 27 August 2018, 21:33:49 UTC Merge branch 'sg/t3420-autostash-fix' Test fixes. * sg/t3420-autostash-fix: t3420-rebase-autostash: don't try to grep non-existing files 27 August 2018, 21:33:49 UTC
5f0ed3e Junio C Hamano 27 August 2018, 21:33:48 UTC Merge branch 'sg/t3903-missing-fix' Test fixes. * sg/t3903-missing-fix: t3903-stash: don't try to grep non-existing file 27 August 2018, 21:33:48 UTC
1d27164 Junio C Hamano 27 August 2018, 21:33:48 UTC Merge branch 'sg/t7501-thinkofix' Test fixes. * sg/t7501-thinkofix: t7501-commit: drop silly command substitution 27 August 2018, 21:33:48 UTC
df19317 Junio C Hamano 27 August 2018, 21:33:46 UTC Merge branch 'sg/t0020-conversion-fix' Test fixes. * sg/t0020-conversion-fix: t0020-crlf: check the right file 27 August 2018, 21:33:47 UTC
603160b Junio C Hamano 27 August 2018, 21:33:45 UTC Merge branch 'sg/t4051-fix' Test fixes. * sg/t4051-fix: t4051-diff-function-context: read the right file 27 August 2018, 21:33:45 UTC
1392c5d Junio C Hamano 27 August 2018, 21:33:44 UTC Merge branch 'js/larger-timestamps' Portability fix. * js/larger-timestamps: commit: use timestamp_t for author_date_slab 27 August 2018, 21:33:44 UTC
6d9276e Junio C Hamano 27 August 2018, 21:33:43 UTC Merge branch 'jk/use-compat-util-in-test-tool' Dev tool update. * jk/use-compat-util-in-test-tool: test-tool.h: include git-compat-util.h 27 August 2018, 21:33:43 UTC
986c518 Junio C Hamano 27 August 2018, 21:33:43 UTC Merge branch 'sg/test-must-be-empty' Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s' 27 August 2018, 21:33:43 UTC
fc0df93 Junio C Hamano 27 August 2018, 21:33:43 UTC Merge branch 'rs/opt-updates' "git cmd -h" updates. * rs/opt-updates: parseopt: group literal string alternatives in argument help remote: improve argument help for add --mirror checkout-index: improve argument help for --stage 27 August 2018, 21:33:43 UTC
6e96e88 Junio C Hamano 27 August 2018, 21:33:42 UTC Merge branch 'nd/complete-config-vars' "git help --config" (which is used in command line completion) missed the configuration variables not described in the main config.txt file but are described in another file that is included by it, which has been corrected. * nd/complete-config-vars: generate-cmdlist.sh: collect config from all config.txt files 27 August 2018, 21:33:42 UTC
7ae96e3 Junio C Hamano 27 August 2018, 21:33:42 UTC Merge branch 'ab/unconditional-free-and-null' Code clean-up. * ab/unconditional-free-and-null: refactor various if (x) FREE_AND_NULL(x) to just FREE_AND_NULL(x) 27 August 2018, 21:33:42 UTC
a988ce9 Junio C Hamano 27 August 2018, 21:33:42 UTC Merge branch 'ep/worktree-quiet-option' "git worktree" command learned "--quiet" option to make it less verbose. * ep/worktree-quiet-option: worktree: add --quiet option 27 August 2018, 21:33:42 UTC
d89db6f Junio C Hamano 27 August 2018, 21:33:42 UTC Merge branch 'sm/branch-sort-config' "git branch --list" learned to take the default sort order from the 'branch.sort' configuration variable, just like "git tag --list" pays attention to 'tag.sort'. * sm/branch-sort-config: branch: support configuring --sort via .gitconfig 27 August 2018, 21:33:42 UTC
9b73732 Junio C Hamano 27 August 2018, 21:33:42 UTC Merge branch 'nd/config-core-checkstat-doc' The meaning of the possible values the "core.checkStat" configuration variable can take were not adequately documented, which has been fixed. * nd/config-core-checkstat-doc: config.txt: clarify core.checkStat 27 August 2018, 21:33:42 UTC
4a3ed63 Ævar Arnfjörð Bjarmason 24 August 2018, 15:20:16 UTC tests: fix and add lint for non-portable grep --file The --file option to grep isn't in POSIX[1], but -f is[1]. Let's check for that in the future, and fix the portability regression in f237c8b6fe ("commit-graph: implement git-commit-graph write", 2018-04-02) that broke e.g. AIX. 1. http://pubs.opengroup.org/onlinepubs/009695399/utilities/grep.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 21:07:32 UTC
8c97e38 Ævar Arnfjörð Bjarmason 24 August 2018, 15:20:15 UTC tests: fix version-specific portability issue in Perl JSON The test guarded by PERLJSON added in 75459410ed ("json_writer: new routines to create JSON data", 2018-07-13) assumed that a JSON boolean value like "true" or "false" would be represented as "1" or "0" in Perl. This behavior can't be relied upon, e.g. with JSON.pm 2.50 and JSON::PP. A JSON::PP::Boolean object will be represented as "true" or "false". To work around this let's check if we have any refs left after we check for hashes and arrays, assume those are JSON objects, and coerce them to a known boolean value. The behavior of this test still looks odd to me. Why implement our own ad-hoc encoder just for some one-off test, as opposed to say Perl's own Data::Dumper with Sortkeys et al? But with this change it works, so let's leave it be. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 21:07:32 UTC
a3c4c88 Ævar Arnfjörð Bjarmason 24 August 2018, 15:20:14 UTC tests: use shorter labels in chainlint.sed for AIX sed Improve the portability of chainlint by using shorter labels. On AIX sed will complain about: sed: 0602-417 The label :hereslurp is greater than eight characters This, in combination with the previous fix to this file makes GIT_TEST_CHAIN_LINT=1 (which is the default) working again on AIX without issues, and the "gmake check-chainlint" test also passes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 21:07:18 UTC
72f47be Kyle Meyer 23 August 2018, 21:57:48 UTC range-diff: update stale summary of --no-dual-color 275267937b (range-diff: make dual-color the default mode, 2018-08-13) replaced --dual-color with --no-dual-color but left the option's summary untouched. Rewrite the summary to describe --no-dual-color rather than dual-color. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 20:13:59 UTC
2d9ded8 Ævar Arnfjörð Bjarmason 24 August 2018, 15:20:13 UTC tests: fix comment syntax in chainlint.sed for AIX sed Change a comment in chainlint.sed to appease AIX sed, which would previously print this error: sed: # stash for later printing is not a recognized function 1. https://public-inbox.org/git/CAPig+cTTbU5HFMKgNyrxTp3+kcK46-Fn=4ZH6zDt1oQChAc3KA@mail.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 18:31:43 UTC
b2fa7a2 Ævar Arnfjörð Bjarmason 24 August 2018, 15:20:12 UTC tests: fix and add lint for non-portable seq The seq command is not in POSIX, and doesn't exist on e.g. OpenBSD. We've had the test_seq wrapper since d17cf5f3a3 ("tests: Introduce test_seq", 2012-08-04), but use of it keeps coming back, e.g. in the recently added "fetch negotiator" tests being added here. So let's also add a check to "make test-lint". The regex is aiming to capture the likes of $(seq ..) and "seq" as a stand-alone command, without capturing some existing cases where we e.g. have files called "seq", as \bseq\b would do. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 18:31:18 UTC
2a59a6e Ævar Arnfjörð Bjarmason 24 August 2018, 15:20:11 UTC tests: fix and add lint for non-portable head -c N The "head -c BYTES" option is non-portable (not in POSIX[1]). Change such invocations to use the test_copy_bytes wrapper added in 48860819e8 ("t9300: factor out portable "head -c" replacement", 2016-06-30). This fixes a test added in 9d2e330b17 ("ewah_read_mmap: bounds-check mmap reads", 2018-06-14), which has been breaking t5310-pack-bitmaps.sh on OpenBSD since 2.18.0. The OpenBSD ports already have a similar workaround after their upgrade to 2.18.0[2]. I have not tested this on IRIX, but according to 4de0bbd898 ("t9300: use perl "head -c" clone in place of "dd bs=1 count=16000" kluge", 2010-12-13) this invocation would have broken things there too. Also, change a valgrind-specific codepath in test-lib.sh to use this wrapper. Given where valgrind runs I don't think this would ever become a portability issue in practice, but it's easier to just use the wrapper than introduce some exception for the "make test-lint" check being added here. 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/head.html 2. https://github.com/openbsd/ports/commit/08d5d82eaefe5cf2f125ecc0c6a57df9cf91350c#diff-f7d3c4fabeed1691620d608f1534f5e5 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 August 2018, 18:31:18 UTC
27c929e Jean-Noël Avila 23 August 2018, 21:00:56 UTC i18n: fix mistakes in translated strings Fix typos and convert a question which does not expect to be replied to a simple advice. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 August 2018, 21:29:12 UTC
d915114 Derrick Stolee 23 August 2018, 15:51:19 UTC config: fix commit-graph related config docs The core.commitGraph config setting was accidentally removed from the config documentation. In that same patch, the config setting that writes a commit-graph during garbage collection was incorrectly written to the doc as "gc.commitGraph" instead of "gc.writeCommitGraph". Reported-by: Szeder Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 August 2018, 17:20:54 UTC
7afb0d6 SZEDER Gábor 23 August 2018, 10:09:15 UTC t/lib-rebase.sh: support explicit 'pick' commands in 'fake_editor.sh' The verbose output of the test 'reword without issues functions as intended' in 't3423-rebase-reword.sh', added in a9279c6785 (sequencer: do not squash 'reword' commits when we hit conflicts, 2018-06-19), contains the following error output: sed: -e expression #1, char 2: extra characters after command This error comes from within the 'fake-editor.sh' script created by 'lib-rebase.sh's set_fake_editor() function, and the root cause is the FAKE_LINES="pick 1 reword 2" variable in the test in question, in particular the "pick" word. 'fake-editor.sh' assumes 'pick' to be the default rebase command and doesn't support an explicit 'pick' command in FAKE_LINES. As a result, 'pick' will be used instead of a line number when assembling the following 'sed' script: sed -n picks/^pick/pick/p which triggers the aforementioned error. Luckily, this didn't affect the test's correctness: the erroring 'sed' command doesn't write anything to the todo script, and processing the rest of FAKE_LINES generates the desired todo script, as if that 'pick' command were not there at all. The minimal fix would be to remove the 'pick' word from FAKE_LINES, but that would leave us susceptible to similar issues in the future. Instead, teach the fake-editor script to recognize an explicit 'pick' command, which is still a fairly trivial change. In the future we might want to consider reinforcing this fake editor script with an &&-chain and stricter parsing of the FAKE_LINES variable (e.g. to error out when encountering unknown rebase commands or commands and line numbers in the wrong order). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 August 2018, 16:23:34 UTC
183a638 Jeff King 23 August 2018, 05:02:25 UTC hashcmp: assert constant hash size Prior to 509f6f62a4 (cache: update object ID functions for the_hash_algo, 2018-07-16), hashcmp() called memcmp() with a constant size of 20 bytes. Some compilers were able to turn that into a few quad-word comparisons, which is faster than actually calling memcmp(). In 509f6f62a4, we started using the_hash_algo->rawsz instead. Even though this will always be 20, the compiler doesn't know that while inlining hashcmp() and ends up just generating a call to memcmp(). Eventually we'll have to deal with multiple hash sizes, but for the upcoming v2.19, we can restore some of the original performance by asserting on the size. That gives the compiler enough information to know that the memcmp will always be called with a length of 20, and it performs the same optimization. Here are numbers for p0001.2 run against linux.git on a few versions. This is using -O2 with gcc 8.2.0. Test v2.18.0 v2.19.0-rc0 HEAD ------------------------------------------------------------------------------ 0001.2: 34.24(33.81+0.43) 34.83(34.42+0.40) +1.7% 33.90(33.47+0.42) -1.0% You can see that v2.19 is a little slower than v2.18. This commit ended up slightly faster than v2.18, but there's a fair bit of run-to-run noise (the generated code in the two cases is basically the same). This patch does seem to be consistently 1-2% faster than v2.19. I tried changing hashcpy(), which was also touched by 509f6f62a4, in the same way, but couldn't measure any speedup. Which makes sense, at least for this workload. A traversal of the whole commit graph requires looking up every entry of every tree via lookup_object(). That's many multiples of the numbers of objects in the repository (most of the lookups just return "yes, we already saw that object"). [jn: verified using "make object.s" that the memcmp call goes away.] Reported-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Jeff King <peff@peff.net Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 August 2018, 13:20:58 UTC
2745817 SZEDER Gábor 22 August 2018, 18:13:20 UTC t3420-rebase-autostash: don't try to grep non-existing files Several tests in 't3420-rebase-autostash.sh' start various rebase processes that are expected to fail because of merge conflicts. These tests then run '! grep' to ensure that the autostash feature did its job, and the dirty contents of a file is gone. However, due to the test repo's history and the choice of upstream branch that file shouldn't exist in the conflicted state at all. Consequently, this 'grep' doesn't fail as expected, because it can't find the dirty content, but it fails because it can't open the file. Tighten this check by using 'test_path_is_missing' instead, thereby avoiding unexpected errors from 'grep' as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2018, 18:52:51 UTC
79b04f9 SZEDER Gábor 22 August 2018, 18:13:19 UTC t3903-stash: don't try to grep non-existing file The test 'store updates stash ref and reflog' in 't3903-stash.sh' creates a stash from a new file, runs 'git reset --hard' to throw away any modifications to the work tree, and then runs '! grep' to ensure that the staged contents are gone. Since the file didn't exist before, it shouldn't exist after 'git reset' either. Consequently, this 'grep' doesn't fail as expected, because it can't find the staged content, but it fails because it can't open the file. Tighten this check by using 'test_path_is_missing' instead, thereby avoiding an unexpected error from 'grep' as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2018, 18:52:35 UTC
29d9e3e Junio C Hamano 22 August 2018, 18:17:05 UTC Merge branch 'nd/pack-deltify-regression-fix' In a recent update in 2.18 era, "git pack-objects" started producing a larger than necessary packfiles by missing opportunities to use large deltas. * nd/pack-deltify-regression-fix: pack-objects: fix performance issues on packing large deltas 22 August 2018, 18:17:05 UTC
b89b4a6 SZEDER Gábor 22 August 2018, 17:48:20 UTC t6018-rev-list-glob: fix 'empty stdin' test Prior to d3c6751b18 (tests: make use of the test_must_be_empty function, 2018-07-27), in the test 'rev-list should succeed with empty output on empty stdin' in 't6018-rev-list-glob' the empty 'expect' file served dual purpose: besides specifying the expected output, as usual, it also served as empty input for 'git rev-list --stdin'. Then d3c6751b18 came along, and, as part of the conversion to 'test_must_be_empty', removed this empty 'expect' file, not realizing its secondary purpose. Redirecting stdin from the now non-existing file failed the test, but since this test expects failure in the first place, this issue went unnoticed. Redirect 'git rev-list's stdin explicitly from /dev/null to provide empty input. (Strictly speaking we don't need this redirection, because the test script's stdin is already redirected from /dev/null anyway, but I think it's better to be explicit about it.) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2018, 18:02:07 UTC
c8b35b9 SZEDER Gábor 22 August 2018, 12:44:37 UTC t4051-diff-function-context: read the right file The test ' context does not include preceding empty lines' in the block of tests 'change with long common tail and no context' in 't4051-diff-function-context.sh' tries to read the file 'long_common_tail.diff.diff', but that file doesn't exist as its name contains one more '.diff' suffixes than necessary. Despite this error the test still succeeded without checking what it's supposed to, because this erroneous read is done on the line: test "$(first_context_line <long_common_tail.diff.diff)" != " " which means that: - the command substitution hides the error, so it won't fail the test, and - the result of the command substitution is the empty string, which is, of course, not equal to a single space character, so the condition is fulfilled, and the test succeeds. As a minimal fix, fix the name of the file to be read. In the future we might want to reorganize this test script (1) to use 'test_cmp' instead of 'test's and command substitutions to catch failing commands and to provide helpful error messages, and (2) to specify what the expected result actually _is_ instead of what it isn't. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2018, 16:14:24 UTC
30612cb SZEDER Gábor 22 August 2018, 12:44:36 UTC t0020-crlf: check the right file In the test 'checkout with autocrlf=input' in 't0020-crlf.sh', one of the 'has_cr' checks looks at the non-existing file 'two' instead of 'dir/two'. The test still succeeds, without actually checking what it was supposed to, because this check is expected to fail anyway. As a minimal fix, fix the name of the file to be checked. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2018, 16:08:08 UTC
15da753 SZEDER Gábor 21 August 2018, 23:28:11 UTC t7501-commit: drop silly command substitution The test '--dry-run with conflicts fixed from a merge' in 't7501-commit.sh', added in 8dc874b2ee (wt-status.c: set commitable bit if there is a meaningful merge., 2016-02-15), runs the following unnecessary and downright bogus command substitution: ! $(git merge --no-commit commit-1) && I.e. after 'git merge ...' is executed and expectedly fails, the test attempts to execute its output: Merging: 80f2ea2 commit 2 virtual commit-1 found 1 common ancestor: e60d113 Initial commit Auto-merging test-file CONFLICT (content): Merge conflict in test-file Automatic merge failed; fix conflicts and then commit the result. as a command, which most likely fails, because there is no such command as "Merging:". Then '!' negates the failed exit status, the test continues, and eventually succeeds. Remove this command substitution and use 'test_must_fail' to ensure that 'git merge' fails. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2018, 15:39:31 UTC
1820703 Derrick Stolee 21 August 2018, 20:54:12 UTC commit: use timestamp_t for author_date_slab The author_date_slab is used to store the author date of a commit when walking with the --author-date flag in rev-list or log. This was added as an 'unsigned long' in 81c6b38b "log: --author-date-order" Since 'unsigned long' is ambiguous in its bit-ness across platforms (64-bit in Linux, 32-bit in Windows, for example), most references to the author dates in commit.c were converted to timestamp_t in dddbad72 "timestamp_t: a new data type for timestamps" However, the slab definition was missed, leading to a mismatch in the data types in Windows. This would not reveal itself as a bug unless someone authors a commit after February 2106, but commits can store anything as their author date. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 21:08:18 UTC
69d846f Jeff King 21 August 2018, 18:41:40 UTC test-tool.h: include git-compat-util.h The test-tool programs include "test-tool.h" as their first include, which breaks our CodingGuideline of "the first include must be git-compat-util.h or an equivalent". Rather than change them all, let's instead make test-tool.h one of those equivalents, just like we do for builtin.h (which many of the actual git builtins include first). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 19:11:40 UTC
1c5e94f SZEDER Gábor 19 August 2018, 21:57:25 UTC tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:48:36 UTC
ec21ac8 SZEDER Gábor 19 August 2018, 21:57:24 UTC tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' Using 'test_must_be_empty' is more idiomatic than 'test_cmp /dev/null out', and its message on error is perhaps a bit more to the point. This patch was basically created by running: sed -i -e 's%test_cmp /dev/null%test_must_be_empty%' t[0-9]*.sh with the exception of the change in 'should not fail in an empty repo' in 't7401-submodule-summary.sh', where it was 'test_cmp output /dev/null'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:48:34 UTC
f0dc593 SZEDER Gábor 19 August 2018, 21:57:23 UTC tests: use 'test_must_be_empty' instead of 'test ! -s' Using 'test_must_be_empty' is preferable to 'test ! -s', because it gives a helpful error message if the given file is unexpectedly no empty, while the latter remains completely silent. Furthermore, it also catches cases when the given file unexpectedly does not exist at all. This patch was created by: sed -i -e 's/test ! -s/test_must_be_empty/' t[0-9]*.sh Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:48:31 UTC
ec10b01 SZEDER Gábor 19 August 2018, 21:57:22 UTC tests: use 'test_must_be_empty' instead of '! test -s' Using 'test_must_be_empty' is preferable to '! test -s', because it gives a helpful error message if the given file is unexpectedly not empty, while the latter remains completely silent. Furthermore, it also catches cases when the given file unexpectedly does not exist at all. This patch was basically created by: sed -i -e 's/! test -s/test_must_be_empty/' t[0-9]*.sh with the following notable exceptions: - The '! test -s' check in '.gitmodules ignore=dirty suppresses submodules with untracked content' in 't7508-status.sh' is left as-is, because it's bogus and, therefore, it's subject of a dedicated patch. - The '! test -s' checks in 't9131-git-svn-empty-symlink.sh' and 't9135-git-svn-moved-branch-empty-file.sh' are immediately preceeded by a 'test -f' to ensure that the files exist in the first place. 'test_must_be_empty' ensures that as well, so those 'test -f' commands are removed as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:48:29 UTC
bbc072f René Scharfe 19 August 2018, 17:34:48 UTC parseopt: group literal string alternatives in argument help This formally clarifies that the "--option=" part is the same for all alternatives. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:35:54 UTC
446e63c René Scharfe 19 August 2018, 17:34:43 UTC remote: improve argument help for add --mirror Group the possible values using a pair of parentheses and don't mark them for translation, as they are literal strings that have to be used as-is in any locale. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:33:21 UTC
168f32e René Scharfe 19 August 2018, 17:34:35 UTC checkout-index: improve argument help for --stage Spell out all alternatives and avoid using a numerical range operator, as it is not mentioned in CodingGuidelines and the resulting string is still concise. Wrap them in parentheses to document clearly that the "--stage=" part is common among them. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:32:44 UTC
eb90ea7 Nguyễn Thái Ngọc Duy 19 August 2018, 10:52:10 UTC generate-cmdlist.sh: collect config from all config.txt files This script uses Documentation/config.txt as input for "git help --config" and "git config" completion but it misses the fact that config.txt includes other txt files. Include all *config.txt as input when scanning for config keys. This could produce false positives, but as long as we stick to the blah-config.txt naming convention, we should be ok. While at there, move diff.* from config.txt to diff-config.txt where all other diff config keys are. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2018, 18:28:11 UTC
back to top