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
1a27b78 Junio C Hamano 29 July 2019, 19:38:16 UTC Merge branch 'es/local-atomic-push-failure-with-http' into maint "git push --atomic" that goes over the transport-helper (namely, the smart http transport) failed to prevent refs to be pushed when it can locally tell that one of the ref update will fail without having to consult the other end, which has been corrected. * es/local-atomic-push-failure-with-http: transport-helper: avoid var decl in for () loop control transport-helper: enforce atomic in push_refs_with_push 29 July 2019, 19:38:16 UTC
0c47e8d Junio C Hamano 29 July 2019, 19:38:16 UTC Merge branch 'po/doc-branch' into maint Doc update. * po/doc-branch: doc branch: provide examples for listing remote tracking branches 29 July 2019, 19:38:16 UTC
747201d Junio C Hamano 29 July 2019, 19:38:15 UTC Merge branch 'dl/config-alias-doc' into maint Doc update. * dl/config-alias-doc: config/alias.txt: document alias accepting non-command first word config/alias.txt: change " and ' to ` 29 July 2019, 19:38:15 UTC
ea21965 Junio C Hamano 29 July 2019, 19:38:15 UTC Merge branch 'cb/fsmonitor-intfix' into maint Variable type fix. * cb/fsmonitor-intfix: fsmonitor: avoid signed integer overflow / infinite loop 29 July 2019, 19:38:15 UTC
90334a8 Junio C Hamano 29 July 2019, 19:38:15 UTC Merge branch 'rs/copy-array' into maint Code clean-up. * rs/copy-array: use COPY_ARRAY for copying arrays coccinelle: use COPY_ARRAY for copying arrays 29 July 2019, 19:38:15 UTC
0726f13 Junio C Hamano 29 July 2019, 19:38:14 UTC Merge branch 'js/t3404-typofix' into maint Typofix. * js/t3404-typofix: t3404: fix a typo 29 July 2019, 19:38:14 UTC
82ac2fb Junio C Hamano 29 July 2019, 19:38:14 UTC Merge branch 'cb/mkstemps-uint-type-fix' into maint Variable type fix. * cb/mkstemps-uint-type-fix: wrapper: avoid undefined behaviour in macOS 29 July 2019, 19:38:14 UTC
dc55e3e Junio C Hamano 29 July 2019, 19:38:14 UTC Merge branch 'js/t0001-case-insensitive' into maint Test update. * js/t0001-case-insensitive: t0001: fix on case-insensitive filesystems 29 July 2019, 19:38:14 UTC
63d9fa2 Junio C Hamano 29 July 2019, 19:38:13 UTC Merge branch 'jw/gitweb-sample-update' into maint Doc update. * jw/gitweb-sample-update: doc: don't use git.kernel.org as example gitweb URL 29 July 2019, 19:38:13 UTC
0a2e838 Junio C Hamano 29 July 2019, 19:38:13 UTC Merge branch 'sg/t5551-fetch-smart-error-is-translated' into maint Test update. * sg/t5551-fetch-smart-error-is-translated: t5551: use 'test_i18ngrep' to check translated output 29 July 2019, 19:38:13 UTC
ca9eba8 Junio C Hamano 29 July 2019, 19:38:13 UTC Merge branch 'jt/t5551-test-chunked' into maint Update smart-http test. * jt/t5551-test-chunked: t5551: test usage of chunked encoding explicitly 29 July 2019, 19:38:13 UTC
bcb30d7 Junio C Hamano 29 July 2019, 19:38:13 UTC Merge branch 'sg/git-C-empty-doc' into maint Doc update. * sg/git-C-empty-doc: Document that 'git -C ""' works and doesn't change directory 29 July 2019, 19:38:13 UTC
3846f5c Junio C Hamano 29 July 2019, 19:38:12 UTC Merge branch 'sg/ci-brew-gcc-workaround' into maint Dev support update. * sg/ci-brew-gcc-workaround: ci/lib.sh: update a comment about installed P4 and Git-LFS versions ci: disable Homebrew's auto cleanup ci: don't update Homebrew 29 July 2019, 19:38:12 UTC
8926ea6 Junio C Hamano 29 July 2019, 19:38:12 UTC Merge branch 'js/trace2-signo-typofix' into maint Documentation fix. * js/trace2-signo-typofix: trace2: correct trace2 field name documentation 29 July 2019, 19:38:12 UTC
c8823b4 Junio C Hamano 29 July 2019, 19:38:12 UTC Merge branch 'di/readme-markup-fix' into maint Docfix. * di/readme-markup-fix: README: fix rendering of text in angle brackets 29 July 2019, 19:38:12 UTC
9d98862 Junio C Hamano 29 July 2019, 19:38:12 UTC Merge branch 'vn/xmmap-gently' into maint Clean-up an error codepath. * vn/xmmap-gently: read-cache.c: do not die if mmap fails 29 July 2019, 19:38:12 UTC
2b31284 Junio C Hamano 29 July 2019, 19:38:12 UTC Merge branch 'rm/gpg-program-doc-fix' into maint Docfix. * rm/gpg-program-doc-fix: gpg(docs): use correct --verify syntax 29 July 2019, 19:38:12 UTC
58f6cfd Junio C Hamano 29 July 2019, 19:38:11 UTC Merge branch 'js/unmap-before-ext-diff' into maint Windows update. * js/unmap-before-ext-diff: diff: munmap() file contents before running external diff 29 July 2019, 19:38:11 UTC
9147e5a Junio C Hamano 29 July 2019, 19:38:11 UTC Merge branch 'js/gcc-8-and-9' into maint Code clean-up for new compilers. The 'kwset' one may get a wholesale replacement, either with new version of kwset from upstream or removal of its users, but in the meantime, it is probably OK to merge it down. * js/gcc-8-and-9: config: avoid calling `labs()` on too-large data type winansi: simplify loading the GetCurrentConsoleFontEx() function kwset: allow building with GCC 8 poll (mingw): allow compiling with GCC 8 and DEVELOPER=1 29 July 2019, 19:38:11 UTC
d61e6ce SZEDER Gábor 29 July 2019, 09:59:14 UTC Documentation/git-fsck.txt: include fsck.* config variables The 'fsck.skipList' and 'fsck.<msg-id>' config variables might be easier to discover when they are documented in 'git fsck's man page. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 July 2019, 17:41:18 UTC
81ed2b4 Carlo Marcelo Arenas Belón 28 July 2019, 20:07:24 UTC xdiff: remove duplicate headers from xpatience.c 92b7de93fb (Implement the patience diff algorithm, 2009-01-07) added them but were already part of xinclude.h Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 July 2019, 04:51:22 UTC
29a0f90 Carlo Marcelo Arenas Belón 28 July 2019, 20:07:23 UTC xdiff: remove duplicate headers from xhistogram.c 8c912eea94 ("teach --histogram to diff", 2011-07-12) included them, but were already part of xinclude.h Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 July 2019, 04:51:21 UTC
0d0e1e8 Carlo Marcelo Arenas Belón 28 July 2019, 20:07:22 UTC xdiff: drop system includes in xutils.c After b46054b374 ("xdiff: use git-compat-util", 2019-04-11), two system headers added with 6942efcfa9 ("xdiff: load full words in the inner loop of xdl_hash_record", 2012-04-06) to xutils.c are no longer needed and could conflict as shown below from an OpenIndiana build: In file included from xdiff/xinclude.h:26:0, from xdiff/xutils.c:25: ./git-compat-util.h:4:0: warning: "_FILE_OFFSET_BITS" redefined #define _FILE_OFFSET_BITS 64 In file included from /usr/include/limits.h:37:0, from xdiff/xutils.c:23: /usr/include/sys/feature_tests.h:231:0: note: this is the location of the previous definition #define _FILE_OFFSET_BITS 32 Make sure git-compat-util.h is the first header (through xinclude.h) Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 July 2019, 04:51:19 UTC
98e06de Junio C Hamano 25 July 2019, 21:32:36 UTC Flush fixes up to the third batch post 2.22.0 Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 July 2019, 21:32:36 UTC
352253a Junio C Hamano 25 July 2019, 21:27:16 UTC Merge branch 'ab/hash-object-doc' into maint Doc update. * ab/hash-object-doc: hash-object doc: stop mentioning git-cvsimport 25 July 2019, 21:27:16 UTC
4098130 Junio C Hamano 25 July 2019, 21:27:15 UTC Merge branch 'cm/send-email-document-req-modules' into maint A doc update. * cm/send-email-document-req-modules: send-email: update documentation of required Perl modules 25 July 2019, 21:27:15 UTC
fe3ec21 Junio C Hamano 25 July 2019, 21:27:15 UTC Merge branch 'sw/git-p4-unshelve-branched-files' into maint "git p4" update. * sw/git-p4-unshelve-branched-files: git-p4: allow unshelving of branched files 25 July 2019, 21:27:15 UTC
2c30e34 Junio C Hamano 25 July 2019, 21:27:14 UTC Merge branch 'js/bisect-helper-check-get-oid-return-value' into maint Code cleanup. * js/bisect-helper-check-get-oid-return-value: bisect--helper: verify HEAD could be parsed before continuing 25 July 2019, 21:27:14 UTC
24c161d Junio C Hamano 25 July 2019, 21:27:14 UTC Merge branch 'es/git-debugger-doc' into maint Doc update. * es/git-debugger-doc: doc: hint about GIT_DEBUGGER in CodingGuidelines 25 July 2019, 21:27:14 UTC
27e4131 Junio C Hamano 25 July 2019, 21:27:14 UTC Merge branch 'mo/clang-format-for-each-update' into maint The list of for-each like macros used by clang-format has been updated. * mo/clang-format-for-each-update: clang-format: use git grep to generate the ForEachMacros list 25 July 2019, 21:27:14 UTC
d7267d5 Junio C Hamano 25 July 2019, 21:27:13 UTC Merge branch 'md/url-parse-harden' into maint The URL decoding code has been updated to avoid going past the end of the string while parsing %-<hex>-<hex> sequence. * md/url-parse-harden: url: do not allow %00 to represent NUL in URLs url: do not read past end of buffer 25 July 2019, 21:27:13 UTC
167d02a Junio C Hamano 25 July 2019, 21:27:13 UTC Merge branch 'an/ignore-doc-update' into maint The description about slashes in gitignore patterns (used to indicate things like "anchored to this level only" and "only matches directories") has been revamped. * an/ignore-doc-update: gitignore.txt: make slash-rules more readable 25 July 2019, 21:27:13 UTC
43f40de Junio C Hamano 25 July 2019, 21:27:12 UTC Merge branch 'md/list-objects-filter-memfix' into maint The filter_data used in the list-objects-filter (which manages a lazily sparse clone repository) did not use the dynamic array API correctly---'nr' is supposed to point at one past the last element of the array in use. This has been corrected. * md/list-objects-filter-memfix: list-objects-filter: correct usage of ALLOC_GROW 25 July 2019, 21:27:12 UTC
f54a2a8 Junio C Hamano 25 July 2019, 21:27:12 UTC Merge branch 'jt/partial-clone-missing-ref-delta-base' into maint "git fetch" into a lazy clone forgot to fetch base objects that are necessary to complete delta in a thin packfile, which has been corrected. * jt/partial-clone-missing-ref-delta-base: t5616: cover case of client having delta base t5616: use correct flag to check object is missing index-pack: prefetch missing REF_DELTA bases t5616: refactor packfile replacement 25 July 2019, 21:27:12 UTC
9db52cf Junio C Hamano 25 July 2019, 21:27:12 UTC Merge branch 'xl/record-partial-clone-origin' into maint When creating a partial clone, the object filtering criteria is recorded for the origin of the clone, but this incorrectly used a hardcoded name "origin" to name that remote; it has been corrected to honor the "--origin <name>" option. * xl/record-partial-clone-origin: clone: respect user supplied origin name when setting up partial clone 25 July 2019, 21:27:12 UTC
58f3484 Junio C Hamano 25 July 2019, 21:27:11 UTC Merge branch 'pb/request-pull-verify-remote-ref' into maint "git request-pull" learned to warn when the ref we ask them to pull from in the local repository and in the published repository are different. * pb/request-pull-verify-remote-ref: request-pull: warn if the remote object is not the same as the local one request-pull: quote regex metacharacters in local ref 25 July 2019, 21:27:11 UTC
0eb2774 Junio C Hamano 25 July 2019, 21:27:11 UTC Merge branch 'mm/p4-unshelve-windows-fix' into maint The command line to invoke a "git cat-file" command from inside "git p4" was not properly quoted to protect a caret and running a broken command on Windows, which has been corrected. * mm/p4-unshelve-windows-fix: p4 unshelve: fix "Not a valid object name HEAD0" on Windows 25 July 2019, 21:27:11 UTC
7a779ca Junio C Hamano 25 July 2019, 21:27:10 UTC Merge branch 'bb/unicode-12.1-reiwa' into maint Update to Unicode 12.1 width table. * bb/unicode-12.1-reiwa: unicode: update the width tables to Unicode 12.1 25 July 2019, 21:27:11 UTC
10432cc Junio C Hamano 25 July 2019, 21:27:10 UTC Merge branch 'js/fsmonitor-unflake' into maint The data collected by fsmonitor was not properly written back to the on-disk index file, breaking t7519 tests occasionally, which has been corrected. * js/fsmonitor-unflake: mark_fsmonitor_valid(): mark the index as changed if needed fill_stat_cache_info(): prepare for an fsmonitor fix 25 July 2019, 21:27:10 UTC
33f2790 Junio C Hamano 25 July 2019, 21:27:10 UTC Merge branch 'vv/merge-squash-with-explicit-commit' into maint "git merge --squash" is designed to update the working tree and the index without creating the commit, and this cannot be countermanded by adding the "--commit" option; the command now refuses to work when both options are given. * vv/merge-squash-with-explicit-commit: merge: refuse --commit with --squash 25 July 2019, 21:27:10 UTC
abbd504 Junio C Hamano 25 July 2019, 21:27:09 UTC Merge branch 'js/bundle-verify-require-object-store' into maint "git bundle verify" needs to see if prerequisite objects exist in the receiving repository, but the command did not check if we are in a repository upfront, which has been corrected. * js/bundle-verify-require-object-store: bundle verify: error out if called without an object database 25 July 2019, 21:27:10 UTC
5bbbd57 Junio C Hamano 25 July 2019, 21:27:09 UTC Merge branch 'jk/am-i-resolved-fix' into maint "git am -i --resolved" segfaulted after trying to see a commit as if it were a tree, which has been corrected. * jk/am-i-resolved-fix: am: fix --interactive HEAD tree resolution am: drop tty requirement for --interactive am: read interactive input from stdin am: simplify prompt response handling 25 July 2019, 21:27:09 UTC
5ca0db3 Junio C Hamano 25 July 2019, 21:27:09 UTC Merge branch 'jk/HEAD-symref-in-xfer-namespaces' into maint The server side support for "git fetch" used to show incorrect value for the HEAD symbolic ref when the namespace feature is in use, which has been corrected. * jk/HEAD-symref-in-xfer-namespaces: upload-pack: strip namespace from symref data 25 July 2019, 21:27:09 UTC
776d668 Junio C Hamano 25 July 2019, 21:27:08 UTC Merge branch 'ew/server-info-remove-crufts' into maint "git update-server-info" used to leave stale packfiles in its output, which has been corrected. * ew/server-info-remove-crufts: server-info: do not list unlinked packs 25 July 2019, 21:27:08 UTC
518e874 Junio C Hamano 25 July 2019, 21:27:08 UTC Merge branch 'es/grep-require-name-when-needed' into maint More parameter validation. * es/grep-require-name-when-needed: grep: fail if call could output and name is null 25 July 2019, 21:27:08 UTC
90891c6 Junio C Hamano 25 July 2019, 21:27:08 UTC Merge branch 'ds/object-info-for-prefetch-fix' into maint Code cleanup and futureproof. * ds/object-info-for-prefetch-fix: sha1-file: split OBJECT_INFO_FOR_PREFETCH 25 July 2019, 21:27:08 UTC
dae2954 Junio C Hamano 25 July 2019, 21:27:07 UTC Merge branch 'mh/import-transport-fd-fix' into maint The ownership rule for the file descriptor to fast-import remote backend was mixed up, leading to unrelated file descriptor getting closed, which has been fixed. * mh/import-transport-fd-fix: Use xmmap_gently instead of xmmap in use_pack dup() the input fd for fast-import used for remote helpers 25 July 2019, 21:27:07 UTC
933f294 Junio C Hamano 25 July 2019, 21:27:07 UTC Merge branch 'nd/corrupt-worktrees' into maint "git worktree add" used to fail when another worktree connected to the same repository was corrupt, which has been corrected. * nd/corrupt-worktrees: worktree add: be tolerant of corrupt worktrees 25 July 2019, 21:27:07 UTC
35d7715 Junio C Hamano 25 July 2019, 21:27:06 UTC Merge branch 'nd/init-relative-template-fix' into maint A relative pathname given to "git init --template=<path> <repo>" ought to be relative to the directory "git init" gets invoked in, but it instead was made relative to the repository, which has been corrected. * nd/init-relative-template-fix: init: make --template path relative to $CWD 25 July 2019, 21:27:06 UTC
b777f3f Jeff King 23 July 2019, 19:27:05 UTC xdiff: clamp function context indices in post-image After finding a function line for --function-context in the pre-image, xdl_emit_diff() calculates the equivalent line in the post-image. It assumes that the lines between changes are the same on both sides. If the option --ignore-blank-lines was also given then this is not necessarily true. Clamp the calculation results for start and end of the function context to prevent out-of-bounds array accesses. Note that this _just_ fixes the case where our mismatch sends us off the beginning of the file. There are likely other cases where our assumption causes us to go to the wrong line within the file. Nobody has developed a test case yet, and the ultimate fix is likely more complicated than this patch. But this at least prevents a segfault in the meantime. Credit for finding the bug goes to "Liu Wei of Tencent Security Xuanwu Lab". Reported-by: 刘炜 <lw17qhdz@gmail.com> Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 July 2019, 21:26:13 UTC
b09364c Johannes Schindelin 18 July 2019, 09:30:33 UTC clean: show an error message when the path is too long When `lstat()` failed, `git clean` would abort without an error message, leaving the user quite puzzled. In particular on Windows, where the default maximum path length is quite small (yet there are ways to circumvent that limit in many cases), it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported this issue: https://github.com/git-for-windows/git/issues/521 Note that we temporarily set `core.longpaths = false` in the regression test; this ensures forward-compatibility with the `core.longpaths` feature that has not yet been upstreamed from Git for Windows. Helped-by: René Scharfe <l.s.r@web.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 July 2019, 15:12:44 UTC
cc0c429 Junio C Hamano 16 July 2019, 17:21:20 UTC CodingGuidelines: spell out post-C89 rules Even though we have been sticking to C89, there are a few handy features we borrow from more recent C language in our codebase after trying them in weather balloons and saw that nobody screamed. Spell them out. While at it, extend the existing variable declaration rule a bit to read better with the newly spelled out rule for the for loop. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 July 2019, 22:16:04 UTC
7926cee Doug Ilijev 18 July 2019, 19:08:45 UTC README: fix rendering of text in angle brackets Markdown incorrectly interpreted `<commandname>` as an HTML tag; use backticks to escape `Documentation/git-<commandname>.txt` to ensure that it renders the text as intended. Signed-off-by: Doug Ilijev <doug.ilijev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 July 2019, 21:47:46 UTC
b2b1f61 Junio C Hamano 17 July 2019, 20:28:24 UTC rm: resolving by removal is not a warning-worthy event When resolving a conflict on a path in favor of removing it, using "git rm" on it is the standard way to do so. The user however is greeted with a "needs merge" message during that operation: $ git merge side-branch $ edit conflicted-path-1 $ git add conflicted-path-1 $ git rm conflicted-path-2 conflicted-path-2: needs merge rm 'conflicted-path-2' The removal by "git rm" does get performed, but an uninitiated user may find it confusing, "needs merge? so I need to resolve conflict before being able to remove it???" The message is coming from "update-index --refresh" that is called internally to make sure "git rm" knows which paths are clean and which paths are dirty, in order to prevent removal of paths modified relative to the index without the "-f" option. We somehow ended up not squelching this message which seeped through to the UI surface. Use the same mechanism used by "git commit", "git describe", etc. to squelch the message. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 July 2019, 21:47:28 UTC
2581ea3 Junio C Hamano 16 July 2019, 20:28:21 UTC transport-helper: avoid var decl in for () loop control We do allow a few selected C99 constructs in our codebase these days, but this is not among them (yet). Reported-by: Carlo Arenas <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 July 2019, 20:30:33 UTC
eb7c786 Johannes Schindelin 16 July 2019, 14:03:12 UTC mingw: support spawning programs containing spaces in their names On some older Windows versions (e.g. Windows 7), the CreateProcessW() function does not really support spaces in its first argument, lpApplicationName. But it supports passing NULL as lpApplicationName, which makes it figure out the application from the (possibly quoted) first argument of lpCommandLine. Let's use that trick (if we are certain that the first argument matches the executable's path) to support launching programs whose path contains spaces. We will abuse the test-fake-ssh.exe helper to verify that this works and does not regress. This fixes https://github.com/git-for-windows/git/issues/692 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 July 2019, 19:47:37 UTC
64c45dc Steven Roberts 16 July 2019, 18:47:37 UTC gpg-interface: do not scan past the end of buffer If the GPG output ends with trailing blank lines, after skipping them over inside the loop to find the terminating NUL at the end, the loop ends up looking for the next line, starting past the end. Signed-off-by: Steven Roberts <sroberts@fenderq.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 July 2019, 19:15:12 UTC
02638d1 Varun Naik 14 July 2019, 03:01:53 UTC read-cache.c: do not die if mmap fails do_read_index() mmaps the index, or tries to die with an error message on failure. It should call xmmap_gently(), which returns MAP_FAILED, rather than xmmap(), which dies with its own error message. An easy way to cause this mmap to fail is by setting $GIT_INDEX_FILE to a path to a directory and then invoking any command that reads from the index. Signed-off-by: Varun Naik <vcnaik94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 July 2019, 22:22:29 UTC
f7bf24d Robert Morgan 12 July 2019, 15:33:57 UTC gpg(docs): use correct --verify syntax The gpg --verify usage example within the 'gpg.program' variable reference provides an incorrect example of the gpg --verify command arguments. The command argument order, when providing both a detached signature and data, should be signature first and data second: https://gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html Signed-off-by: Robert Morgan <robert.thomas.morgan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 July 2019, 18:14:22 UTC
3bca1e7 Emily Shaffer 11 July 2019, 21:19:19 UTC transport-helper: enforce atomic in push_refs_with_push Teach transport-helper how to notice if skipping a ref during push would violate atomicity on the client side. We notice that a ref would be rejected, and choose not to send it, but don't notice that if the client has asked for --atomic we are violating atomicity if all the other pushes we are sending would succeed. Asking the server end to uphold atomicity wouldn't work here as the server doesn't have any idea that we tried to update a ref that's broken. The added test-case is a succinct way to reproduce this issue that fails today. The same steps work fine when we aren't using a transport-helper to get to the upstream, i.e. when we've added a local repository as a remote: git remote add ~/upstream upstream Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 July 2019, 16:24:10 UTC
3aef54e Johannes Schindelin 11 July 2019, 08:23:41 UTC diff: munmap() file contents before running external diff When running an external diff from, say, a diff tool, it is safe to assume that we want to write the files in question. On Windows, that means that there cannot be any other process holding an open handle to said files, or even just a mapped region. So let's make sure that `git diff` itself is not holding any open handle to the files in question. In fact, we will just release the file pair right away, as the external diff uses the files we just wrote, so we do not need to hold the file contents in memory anymore. This fixes https://github.com/git-for-windows/git/issues/1315 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 July 2019, 19:11:54 UTC
24df0d4 Josh Steadmon 09 July 2019, 23:09:01 UTC trace2: correct trace2 field name documentation Correct the api-trace2 documentation, which lists "signal" as an expected field for the signal event type, but which actually outputs "signo" as the field name. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 July 2019, 23:28:40 UTC
37a2e35 SZEDER Gábor 06 July 2019, 16:21:14 UTC ci/lib.sh: update a comment about installed P4 and Git-LFS versions A comment in 'ci/lib.sh' claims that the "OS X build installs the latest available versions" of P4 and Git-LFS, but since f2f47150 ("ci: don't update Homebrew", 2019-07-03) that's no longer the case, as it will install the versions which were recorded in the image's Homebrew database when the image was created. Update this comment accordingly. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 July 2019, 18:01:48 UTC
af8ed04 SZEDER Gábor 03 July 2019, 10:47:48 UTC ci: disable Homebrew's auto cleanup Lately Homebrew learned to automagically clean up information about outdated packages during other 'brew' commands, which might be useful for the avarage user, but is a waste of time in CI build jobs, because the next build jobs will start from the exact same image containing the same outdated packages anyway. Export HOMEBREW_NO_INSTALL_CLEANUP=1 to disable this auto cleanup feature, shaving off about 20-30s from the time needed to install dependencies in our macOS build jobs on Travis CI. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 July 2019, 16:53:57 UTC
f2f4715 SZEDER Gábor 03 July 2019, 10:47:47 UTC ci: don't update Homebrew Lately our GCC macOS build job on Travis CI has been erroring out while installing dependencies with: +brew link gcc@8 Error: No such keg: /usr/local/Cellar/gcc@8 The command "ci/install-dependencies.sh" failed and exited with 1 during . Now, while gcc@8 is still pre-installed (but not linked) and would be perfectly usable in the Travis CI macOS image we use [1], it's at version 8.2. However, when installing dependencies we first explicitly run 'brew update', which spends over two minutes to update itself and information about the available packages, and it learns about GCC 8.3. After that point gcc@8 exclusively refers to v8.3, and, unfortunately, 'brew' is just too dumb to be able to do anything with the still installed 8.2 package, and the subsequent 'brew link gcc@8' fails. (Even 'brew uninstall gcc@8' fails with the same error!) Don't run 'brew update' to keep the already installed GCC 8.2 'brew link'-able. Note that in addition we have to 'export HOMEBREW_NO_AUTO_UPDATE=1' first, because 'brew' is so very helpful that it would implicitly run update for us on the next 'brew install <pkg>' otherwise. Disabling 'brew update' has additional benefits: - It shaves off 2-3mins from the ~4mins currently spent on installing dependencies, and the macOS build jobs have always been prone to exceeding the time limit on Travis CI. - Our builds won't suddenly break because of the occasional Homebrew breakages [2]. The drawback is that we'll be stuck with slightly older versions of the packages that we install via Homebrew (Git-LFS 2.5.2 and Perforce 2018.1; they are currently at 2.7.2 and 2019.1, respectively). We might want to reconsider this decision as time goes on and/or switch to a more recent macOS image as they become available. [1] 2000ac9fbf (travis-ci: switch to Xcode 10.1 macOS image, 2019-01-17) [2] See e.g. a1ccaedd62 (travis-ci: make the OSX build jobs' 'brew update' more quiet, 2019-02-02) or https://public-inbox.org/git/20180907032002.23366-1-szeder.dev@gmail.com/T/#+u Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 July 2019, 16:53:45 UTC
bfc8c84 Quentin Nerden 02 July 2019, 14:37:41 UTC docs: git-clone: list short form of options first List the short form of options (e.g.: '-l') before the long form (e.g. '--local'). This is to match the doc of git-add, git-commit, git-clean, git-branch... Signed-off-by: Quentin Nerden <quentin.nerden@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 July 2019, 19:11:40 UTC
3711d1c Quentin Nerden 02 July 2019, 14:37:40 UTC docs: git-clone: refer to long form of options To make the doc of git-clone easier to read, refer to the long form of the options (it is easier to guess what '--verbose' is doing than '-v'). Signed-off-by: Quentin Nerden <quentin.nerden@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 July 2019, 19:11:38 UTC
1a64e07 SZEDER Gábor 29 June 2019, 08:24:57 UTC Document that 'git -C ""' works and doesn't change directory It's been behaving so since 6a536e2076 (git: treat "git -C '<path>'" as a no-op when <path> is empty, 2015-03-06). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2019, 17:42:49 UTC
906b639 Johannes Schindelin 01 July 2019, 11:58:15 UTC rebase --am: ignore rebase.rescheduleFailedExec The `exec` command is specific to the interactive backend, therefore it does not make sense for non-interactive rebases to heed that config setting. We still want to error out if a non-interactive rebase is started with `--reschedule-failed-exec`, of course. Reported by Vas Sudanagunta via: https://github.com/git/git/commit/969de3ff0e0#commitcomment-33257187 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2019, 16:43:49 UTC
5b12e31 SZEDER Gábor 24 June 2019, 18:13:18 UTC progress: use term_clear_line() To make sure that the previously displayed progress line is completely covered up when the new line is shorter, commit 545dc345eb (progress: break too long progress bar lines, 2019-04-12) added a bunch of calculations to figure out how many characters it needs to overwrite with spaces. Use the just introduced term_clear_line() helper function to, well, clear the last line, making all these calculations unnecessary, and thus simplifying the code considerably. Three tests in 't5541-http-push-smart.sh' 'grep' for specific text shown in the progress lines at the beginning of the line, but now those lines begin either with the ANSI escape sequence or with the terminal width worth of space characters clearing the line. Relax the 'grep' patterns to match anywhere on the line. Note that only two of these three tests fail without relaxing their 'grep' pattern, but the third looks for the absence of the pattern, so it still succeeds, but without the adjustment would potentially hide future regressions. Note also that with this change we no longer need the length of the previously displayed progress line, so the strbuf added to 'struct progress' in d53ba841d4 (progress: assemble percentage and counters in a strbuf before printing, 2019-04-05) is not strictly necessary anymore. We still keep it, though, as it avoids allocating and releasing a strbuf each time the progress is updated. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2019, 19:58:41 UTC
d7d9088 SZEDER Gábor 27 June 2019, 13:42:48 UTC rebase: fix garbled progress display with '-x' When running a command with the 'exec' instruction during an interactive rebase session, or for a range of commits using 'git rebase -x', the output can be a bit garbled when the name of the command is short enough: $ git rebase -x true HEAD~5 Executing: true Executing: true Executing: true Executing: true Executing: true) Successfully rebased and updated refs/heads/master. Note the ')' at the end of the last line. It gets more garbled as the range of commits increases: $ git rebase -x true HEAD~50 Executing: true) [ repeated 3 more times ] Executing: true0) [ repeated 44 more times ] Executing: true00) Successfully rebased and updated refs/heads/master. Those extra numbers and ')' are remnants of the previously displayed "Rebasing (N/M)" progress lines that are usually completely overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and the "N/M" part is long. Make sure that the previously displayed "Rebasing (N/M)" line is cleared by using the term_clear_line() helper function added in the previous patch. Do so only when not being '--verbose', because in that case these "Rebasing (N/M)" lines are not printed as progress (i.e. as lines with '\r' at the end), but as "regular" output (with '\n' at the end). A couple of other rebase commands print similar messages, e.g. "Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break' commands, or the "Successfully rebased and updated <full-ref>." at the very end. These are so long that they practically always overwrite that "Rebasing (N/M)" progress line, but let's be prudent, and clear the last line before printing these, too. In 't3420-rebase-autostash.sh' two helper functions prepare the expected output of four tests that check the full output of 'git rebase' and thus are affected by this change, so adjust their expectations to account for the new line clearing. Note that this patch doesn't completely eliminate the possibility of similar garbled outputs, e.g. some error messages from rebase or the "Auto-merging <file>" message from within the depths of the merge machinery might not be long enough to completely cover the last "Rebasing (N/M)" line. This patch doesn't do anything about them, because dealing with them individually would result in way too much churn, while having a catch-all term_clear_line() call in the common code path of pick_commits() would hide the "Rebasing (N/M)" line way too soon, and it would either flicker or be invisible. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2019, 19:58:20 UTC
8d45ad8 Jonathan Tan 05 June 2019, 19:26:24 UTC t5551: test usage of chunked encoding explicitly When run using GIT_TEST_PROTOCOL_VERSION=2, a test in t5551 fails because 4 POSTs (probe, ls-refs, probe, fetch) are sent instead of 2 (probe, fetch). One way to resolve this would be to relax the condition (from "= 2" to greater than 1, say), but upon further inspection, the test probably shouldn't be counting the number of POSTs. This test states that large requests are split across POSTs, but this is not correct; the main change is that chunked transfer encoding is used, but the request is still contained within one POST. (The test coincidentally works because Git indeed sends 2 POSTs in the case of a large request, but that is because, as stated above, the first POST is a probing RPC - see post_rpc() in remote-curl.c for more information.) Therefore, instead of counting POSTs, check that chunked transfer encoding is used. This also has the desirable side effect of passing with GIT_TEST_PROTOCOL_VERSION=2. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2019, 17:14:10 UTC
e532a90 SZEDER Gábor 24 June 2019, 12:44:46 UTC t5551: use 'test_i18ngrep' to check translated output The two tests 'invalid Content-Type rejected' and 'server-side error detected' in 't5551-http-fetch-smart.sh' use "plain" 'grep' to check that 'git clone' failed with the expected error message, but the messages they are checking are translated, and, consequently, these tests fail when the test script is run with GIT_TEST_GETTEXT_POISON enabled. Use 'test_i18ngrep' instead. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2019, 19:06:28 UTC
30db18b Morian Sonnet 24 June 2019, 20:26:55 UTC submodule foreach: fix recursion of options Calling git submodule foreach --recursive <subcommand> --<option> leads to an error stating that the option --<option> is unknown to submodule--helper. That is of course only, when <option> is not a valid option for git submodule foreach. The reason for this is, that above call is internally translated into a call to submodule--helper: git submodule--helper foreach --recursive \ -- <subcommand> --<option> This call starts by executing the subcommand with its option inside the first level submodule and continues by calling the next iteration of the submodule foreach call git --super-prefix <submodulepath> submodule--helper \ foreach --recursive <subcommand> --<option> inside the first level submodule. Note that the double dash in front of the subcommand is missing. This problem starts to arise only recently, as the PARSE_OPT_KEEP_UNKNOWN flag for the argument parsing of git submodule foreach was removed in commit a282f5a906. Hence, the unknown option is complained about now, as the argument parsing is not properly ended by the double dash. This commit fixes the problem by adding the double dash in front of the subcommand during the recursion. Signed-off-by: Morian Sonnet <moriansonnet@googlemail.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2019, 18:17:53 UTC
cd1096b SZEDER Gábor 24 June 2019, 18:13:16 UTC pager: add a helper function to clear the last line in the terminal There are a couple of places where we want to clear the last line on the terminal, e.g. when a progress bar line is overwritten by a shorter line, then the end of that progress line would remain visible, unless we cover it up. In 'progress.c' we did this by always appending a fixed number of space characters to the next line (even if it was not shorter than the previous), but as it turned out that fixed number was not quite large enough, see the fix in 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). From then on we've been keeping track of the length of the last displayed progress line and appending the appropriate number of space characters to the next line, if necessary, but, alas, this approach turned out to be error prone, see the fix in 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19). The next patch in this series is about to fix a case where we don't clear the last line, and on occasion do end up with such garbage at the end of the line. It would be great if we could do that without the need to deal with that without meticulously computing the necessary number of space characters. So add a helper function to clear the last line on the terminal using an ANSI escape sequence, which has the advantage to clear the whole line no matter how wide it is, even after the terminal width changed. Such an escape sequence is not available on dumb terminals, though, so in that case fall back to simply print a whole terminal width (as reported by term_columns()) worth of space characters. In 'editor.c' launch_specified_editor() already used this ANSI escape sequence, so replace it with a call to this function. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 20:38:46 UTC
077b979 SZEDER Gábor 24 June 2019, 18:13:15 UTC t3404: make the 'rebase.missingCommitsCheck=ignore' test more focused The test 'rebase -i respects rebase.missingCommitsCheck = warn' is mainly interested in the warning about the dropped commits, but it checks the whole output of 'git rebase', including progress lines and what not that are not at all relevant to 'rebase.missingCommitsCheck', but make it necessary to update this test whenever e.g. the way we show progress is updated (as it will happen in one of the later patches of this series). Modify the test to verify only the first four lines of 'git rebase's output that contain all the important lines, notably the line containing the "Warning:" itself and the oneline log of the dropped commit. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 20:38:46 UTC
c9749b3 SZEDER Gábor 24 June 2019, 18:13:14 UTC t3404: modernize here doc style In 't3404-rebase-interactive.sh' the expected output of several tests is prepared from here documents, which are outside of 'test_expect_success' blocks and have spaces around redirection operators. Move these here documents into the corresponding 'test_expect_success' block and avoid spaces between filename and redition operators. Furthermore, quote the here docs' delimiter word to prevent parameter expansions and what not, where applicable. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 20:38:46 UTC
dfa880e Jakub Wilk 22 June 2019, 16:48:57 UTC doc: don't use git.kernel.org as example gitweb URL git.kernel.org uses cgit, not gitweb, these days: $ w3m -dump 'http://git.kernel.org/?p=git/git.git;a=tree;f=gitweb' | grep -w generated generated by cgit 1.2-0.3.lf.el7 (git 2.18.0) at 2019-06-22 16:14:38 +0000 Signed-off-by: Jakub Wilk <jwilk@jwilk.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 19:37:21 UTC
39c575c René Scharfe 22 June 2019, 10:03:40 UTC config: simplify parsing of unit factors Just return the value of the factor or zero for unrecognized strings instead of using an output reference and a separate return value to indicate success. This is shorter and simpler. It basically reverts that function to before c8deb5a146 ("Improve error messages when int/long cannot be parsed from config", 2007-12-25), while keeping the better messages, so restore its old name, get_unit_factor(), as well. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 19:34:20 UTC
664178e René Scharfe 22 June 2019, 10:03:36 UTC config: don't multiply in parse_unit_factor() parse_unit_factor() multiplies the number that is passed to it with the value of a recognized unit factor (K, M or G for 2^10, 2^20 and 2^30, respectively). All callers pass in 1 as a number, though, which allows them to check the actual multiplication for overflow before they are doing it themselves. Ignore the passed in number and don't multiply, as this feature of parse_unit_factor() is not used anymore. Rename the output parameter to reflect that it's not about the end result anymore, but just about the unit factor. Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 19:34:19 UTC
3fb72c7 René Scharfe 22 June 2019, 10:03:30 UTC config: use unsigned_mult_overflows to check for overflows parse_unit_factor() checks if a K, M or G is present after a number and multiplies it by 2^10, 2^20 or 2^30, respectively. One of its callers checks if the result is smaller than the number alone to detect overflows. The other one passes 1 as the number and does multiplication and overflow check itself in a similar manner. This works, but is inconsistent, and it would break if we added support for a bigger unit factor. E.g. 16777217T is 2^64 + 2^40, i.e. too big for a 64-bit number. Modulo 2^64 we get 2^40 == 1TB, which is bigger than the raw number 16777217 == 2^24 + 1, so the overflow would go undetected by that method. Let both callers pass 1 and handle overflow check and multiplication themselves. Do the check before the multiplication, using unsigned_mult_overflows, which is simpler and can deal with larger unit factors. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 19:34:17 UTC
ed33bd8 Johannes Schindelin 24 June 2019, 17:40:05 UTC t0001: fix on case-insensitive filesystems On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible that the idea Bash has of the current directory differs in case from what Git thinks it is. That's totally okay, though, and we should not expect otherwise. On Windows, for example, when you call cd C:\GIT-SDK-64 in a PowerShell and there exists a directory called `C:\git-sdk-64`, the current directory will be reported in all upper-case. Even in a Bash that you might call from that PowerShell. Git, however, will have normalized this via `GetFinalPathByHandle()`, and the expectation in t0001 that the recorded gitdir will match what `pwd` says will be violated. Let's address this by comparing these paths in a case-insensitive manner when `core.ignoreCase` is `true`. Reported by Jameson Miller. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2019, 18:55:54 UTC
bdbdf42 Jeff King 20 June 2019, 08:58:32 UTC delta-islands: respect progress flag The delta island code always prints "Marked %d islands", even if progress has been suppressed with --no-progress or by sending stderr to a non-tty. Let's pass a progress boolean to load_delta_islands(). We already do the same thing for the progress meter in resolve_tree_islands(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 June 2019, 20:29:49 UTC
63b50c8 Thomas Gummerer 15 June 2019, 11:26:18 UTC stash: fix show referencing stash index In the conversion of 'stash show' to C in dc7bd382b1 ("stash: convert show to builtin", 2019-02-25), 'git stash show <n>', where n is the index of a stash got broken, if n is not a file or a valid revision by itself. 'stash show' accepts any flag 'git diff' accepts for changing the output format. Internally we use 'setup_revisions()' to parse these command line flags. Currently we pass the whole argv through to 'setup_revisions()', which includes the stash index. As the stash index is not a valid revision or a file in the working tree in most cases however, this 'setup_revisions()' call (and thus the whole command) ends up failing if we use this form of 'git stash show'. Instead of passing the whole argv to 'setup_revisions()', only pass the flags (and the command name) through, while excluding the stash reference. The stash reference is parsed (and validated) in 'get_stash_info()' already. This separate parsing also means that we currently do produce the correct output if the command succeeds. Reported-by: Mike Hommey <mh@glandium.org> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 June 2019, 21:47:49 UTC
7a06fb0 Jeff King 18 June 2019, 15:54:19 UTC wt-status.h: drop stdio.h include We started including stdio.h to pick up the declaration of "FILE" in f26a001226 (Enable wt-status output to a given FILE pointer., 2007-09-17). But there's no need, since headers can assume that git-compat-util.h has been included, which covers stdio. This should just be redundant, and not hurting anything (like pulling in includes out of order) because C files are supposed to always include git-compat-util.h first. But it's worth cleaning up to model good behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 June 2019, 15:19:22 UTC
96728b2 Jeff King 18 June 2019, 15:54:09 UTC verify-tag: drop signal.h include There's no reason verify-tag.c needs to include signal.h. It's already in git-compat-util.h, which we properly include as the first header. And there doesn't seem to be a particular reason for this include; it's just an artifact from the file creation in 2ae68fcb78 (Make verify-tag a builtin., 2007-07-27). Likewise verify-commit.c has the same issue, probably because it was created using verify-tag as a template in d07b00b7f3 (verify-commit: scriptable commit signature verification, 2014-06-23). These includes are probably just redundant, and not hurting anything by circumventing the order that git-compat-util.h tries to impose, since we'll always have loaded git-compat-util by the time we get to these. So this is just a cleanup, and shouldn't fix or break any platforms. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 June 2019, 15:19:21 UTC
729a9b5 Carlo Marcelo Arenas Belón 16 June 2019, 18:40:03 UTC wrapper: avoid undefined behaviour in macOS 0620b39b3b ("compat: add a mkstemps() compatibility function", 2009-05-31) included a function based on code from libiberty which would result in undefined behaviour in platforms where timeval's tv_usec is a 32-bit signed type as shown by: wrapper.c:505:31: runtime error: left shift of 594546 by 16 places cannot be represented in type '__darwin_suseconds_t' (aka 'int') interestingly the version of this code from gcc never had this bug and the code had a cast that would had prevented the issue (at least in 64-bit platforms) but was misapplied. change the cast to uint64_t so it also works in 32-bit platforms. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 June 2019, 14:41:31 UTC
29c83fc Jeff King 19 June 2019, 03:37:28 UTC interpret-trailers: load default config The interpret-trailers program does not do the usual loading of config via git_default_config(), and thus does not respect many of the usual options. In particular, we will not load core.commentChar, even though the underlying trailer code uses its value. This can be seen in the accompanying test, where setting core.commentChar to anything besides "#" results in a failure to treat the comments correctly. Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 June 2019, 14:12:49 UTC
921d49b René Scharfe 15 June 2019, 18:36:35 UTC use COPY_ARRAY for copying arrays Convert calls of memcpy(3) to use COPY_ARRAY, which shortens and simplifies the code a bit. Patch generated by Coccinelle and contrib/coccinelle/array.cocci. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 June 2019, 01:15:04 UTC
177fbab René Scharfe 15 June 2019, 18:32:58 UTC coccinelle: use COPY_ARRAY for copying arrays The current semantic patch for COPY_ARRAY transforms memcpy(3) calls on pointers, but Coccinelle distinguishes them from arrays. It already contains three rules to handle the options for sizeof (i.e. source, destination and type), and handling arrays as source and destination would require four times as many rules if we enumerated all cases. We also don't handle array subscripts, and supporting that would increase the number of rules by another factor of four. (An isomorphism telling Coccinelle that "sizeof x[...]" is equivalent to "sizeof *x" would be nice..) Support arrays and array subscripts, but keep the number of rules down by adding normalization steps: First turn array subscripts into derefences, then determine the types of expressions used with sizeof and replace them with these types, and then convert the different possible combinations of arrays and pointers with memcpy(3) to COPY_ARRAY. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 June 2019, 01:14:59 UTC
5d137fc Carlo Marcelo Arenas Belón 15 June 2019, 16:11:35 UTC fsmonitor: avoid signed integer overflow / infinite loop 883e248b8a ("fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.", 2017-09-22) uses an int in a loop that would wrap if index_state->cache_nr (unsigned) is bigger than INT_MAX Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 June 2019, 01:14:29 UTC
cc8d872 Johannes Schindelin 14 June 2019, 12:16:08 UTC t3404: fix a typo This one slipped through the review of a9279c678588 (sequencer: do not squash 'reword' commits when we hit conflicts, 2018-06-19). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 June 2019, 19:30:23 UTC
568a05c René Scharfe 13 June 2019, 17:51:56 UTC cleanup: fix possible overflow errors in binary search, part 2 Calculating the sum of two array indexes to find the midpoint between them can overflow, i.e. code like this is unsafe for big arrays: mid = (first + last) >> 1; Make sure the intermediate value stays within the boundaries instead, like this: mid = first + ((last - first) >> 1); The loop condition of the binary search makes sure that 'last' is always greater than 'first', so this is safe as long as 'first' is not negative. And that can be verified easily using the pre-context of each change, except for name-hash.c, so add an assertion to that effect there. The unsafe calculations were found with: git grep '(.*+.*) *>> *1' This is a continuation of 19716b21a4 (cleanup: fix possible overflow errors in binary search, 2017-10-08). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2019, 18:28:53 UTC
2bd69b9 Phillip Wood 12 June 2019, 09:25:27 UTC add -p: fix checkout -p with pathological context Commit fecc6f3a68 ("add -p: adjust offsets of subsequent hunks when one is skipped", 2018-03-01) fixed adding hunks in the correct place when a previous hunk has been skipped. However it did not address patches that are applied in reverse. In that case we need to adjust the pre-image offset so that when apply reverses the patch the post-image offset is adjusted correctly. We subtract rather than add the delta as the patch is reversed (the easiest way to think about it is to consider a hunk of deletions that is skipped - in that case we want to reduce offset so we need to subtract). Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2019, 17:00:30 UTC
9dae4fe Johannes Schindelin 13 June 2019, 11:49:47 UTC config: avoid calling `labs()` on too-large data type The `labs()` function operates, as the initial `l` suggests, on `long` parameters. However, in `config.c` we tried to use it on values of type `intmax_t`. This problem was found by GCC v9.x. To fix it, let's just "unroll" the function (i.e. negate the value if it is negative). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2019, 16:34:17 UTC
4fa42df Johannes Schindelin 13 June 2019, 11:49:46 UTC winansi: simplify loading the GetCurrentConsoleFontEx() function We introduced helper macros to simplify loading functions dynamically. Might just as well use them. This also side-steps a compiler warning when building with GCC v8.x: it would complain about casting between incompatible function pointers. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2019, 16:34:16 UTC
08e0450 Johannes Schindelin 13 June 2019, 11:49:45 UTC kwset: allow building with GCC 8 The kwset functionality makes use of the obstack code, which expects to be handed a function that can allocate large chunks of data. It expects that function to accept a `size` parameter of type `long`. This upsets GCC 8 on Windows, because `long` does not have the same bit size as `size_t` there. Now, the proper thing to do would be to switch to `size_t`. But this would make us deviate from the "upstream" code even further, making it hard to synchronize with newer versions, and also it would be quite involved because that `long` type is so invasive in that code. Let's punt, and instead provide a super small wrapper around `xmalloc()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2019, 16:34:16 UTC
8d4679f Johannes Schindelin 13 June 2019, 11:49:44 UTC poll (mingw): allow compiling with GCC 8 and DEVELOPER=1 The return type of the `GetProcAddress()` function is `FARPROC` which evaluates to `long long int (*)()`, i.e. it cannot be cast to the correct function signature by GCC 8. To work around that, we first cast to `void *` and go on with our merry lives. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2019, 16:34:16 UTC
2d511cf Derrick Stolee 17 May 2019, 18:41:49 UTC packfile: rename close_all_packs to close_object_store The close_all_packs() method is now responsible for more than just pack-files. It also closes the commit-graph and the multi-pack-index. Rename the function to be more descriptive of its larger role. The name also fits because the input parameter is a raw_object_store. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 June 2019, 18:33:54 UTC
5472c32 Derrick Stolee 17 May 2019, 18:41:48 UTC packfile: close commit-graph in close_all_packs The close_all_packs() method is used to close all read handles to pack-files and the multi-pack-index before running 'git gc --auto'. This is particularly important on the Windows platform, where read handles block any writes to those files. Replacing one of these files with a rename() will fail in this situation. The commit-graph also performs a rename, so is susceptable to this problem. We are careful to close the commit-graph before writing, but that doesn't work when a 'git fetch' (or similar) process runs 'git gc --auto' which may write a commit-graph. Here, close the commit-graph as part of close_all_packs(). Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 June 2019, 18:33:54 UTC
back to top