summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-23Eleventh batchLibravatar Junio C Hamano1-0/+10
The tenth was at -rc0 ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'cb/pcre2-chartables-leakfix'Libravatar Junio C Hamano3-3/+47
Leakfix. * cb/pcre2-chartables-leakfix: grep: avoid leak of chartables in PCRE2 grep: make PCRE2 aware of custom allocator grep: make PCRE1 aware of custom allocator
2019-10-23Merge branch 'bc/smart-http-atomic-push'Libravatar Junio C Hamano5-3/+62
The atomic push over smart HTTP transport did not work, which has been corrected. * bc/smart-http-atomic-push: remote-curl: pass on atomic capability to remote side
2019-10-23Merge branch 'wb/fsmonitor-bitmap-fix'Libravatar Junio C Hamano3-5/+65
A segfault fix. * wb/fsmonitor-bitmap-fix: fsmonitor: don't fill bitmap with entries to be removed
2019-10-23Merge branch 'sb/userdiff-dts'Libravatar Junio C Hamano5-2/+33
Tweak userdiff patterns for dts. * sb/userdiff-dts: userdiff: fix some corner cases in dts regex
2019-10-23Merge branch 'sg/progress-fix'Libravatar Junio C Hamano1-1/+1
Byte-order fix the recent update to progress display code. * sg/progress-fix: test-progress: fix test failures on big-endian systems
2019-10-23Merge branch 'nr/diff-highlight-indent-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * nr/diff-highlight-indent-fix: diff-highlight: fix a whitespace nit
2019-10-23Merge branch 'mb/clarify-zsh-completion-doc'Libravatar Junio C Hamano1-2/+3
The installation instruction for zsh completion script (in contrib/) has been a bit improved. * mb/clarify-zsh-completion-doc: completion: clarify installation instruction for zsh
2019-10-23Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-2/+2
* js/azure-pipelines-msvc: ci(visual-studio): actually run the tests in parallel ci(visual-studio): use strict compile flags, and optimization
2019-10-23ci(visual-studio): actually run the tests in parallelLibravatar Johannes Schindelin1-1/+1
Originally, the CI/PR builds that build and test using Visual Studio were implemented imitating `linux-clang`, i.e. still using the `Makefile`-based build infrastructure. Later (but still before the patches made their way into git.git's `master`), however, this was changed to generate Visual Studio project files and build the binaries using `MSBuild`, as this reflects more accurately how Visual Studio users would want to build Git (internally, Visual Studio uses `MSBuild`, or at least something very similar). During that transition, we needed to implement a new way to run the test suite in parallel, as Visual Studio users typically will only have a Git Bash available (which does not ship with `make` nor with support for `prove`): we simply implemented a new test helper to run the test suite. This helper even knows how to run the tests in parallel, but due to a mistake on this developer's part, it was never turned on in the CI/PR builds. This results in 2x-3x longer run times of the test phase. Let's use the `--jobs=10` option to fix this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23ci(visual-studio): use strict compile flags, and optimizationLibravatar Johannes Schindelin1-1/+1
To make full use of the work that went into the Visual Studio build & test jobs in our CI/PR builds, let's turn on strict compiler flags. This will give us the benefit of Visual C's compiler warnings (which, at times, seem to catch things that GCC does not catch, and vice versa). While at it, also turn on optimization; It does not make sense to produce binaries with debug information, and we can use any ounce of speed that we get (because the test suite is particularly slow on Windows, thanks to the need to run inside a Unix shell, which requires us to use the POSIX emulation layer provided by MSYS2). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21userdiff: fix some corner cases in dts regexLibravatar Stephen Boyd5-2/+33
While reviewing some dts diffs recently I noticed that the hunk header logic was failing to find the containing node. This is because the regex doesn't consider properties that may span multiple lines, i.e. property = <something>, <something_else>; and it got hung up on comments inside nodes that look like the root node because they start with '/*'. Add tests for these cases and update the regex to find them. Maybe detecting the root node is too complicated but forcing it to be a backslash with any amount of whitespace up to an open bracket seemed OK. I tried to detect that a comment is in-between the two parts but I wasn't happy so I just dropped it. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21test-progress: fix test failures on big-endian systemsLibravatar SZEDER Gábor1-1/+1
In 't0500-progress-display.sh' all tests running 'test-tool progress --total=<N>' fail on big-endian systems, e.g. like this: + test-tool progress --total=3 Working hard [...] + test_i18ncmp expect out --- expect 2019-10-18 23:07:54.765523916 +0000 +++ out 2019-10-18 23:07:54.773523916 +0000 @@ -1,4 +1,2 @@ -Working hard: 33% (1/3)<CR> -Working hard: 66% (2/3)<CR> -Working hard: 100% (3/3)<CR> -Working hard: 100% (3/3), done. +Working hard: 0% (1/12884901888)<CR> +Working hard: 0% (3/12884901888), done. The reason for that bogus value is that '--total's parameter is parsed via parse-options's OPT_INTEGER into a uint64_t variable [1], so the two bits of 3 end up in the "wrong" bytes on big-endian systems (12884901888 = 0x300000000). Change the type of that variable from uint64_t to int, to match what parse-options expects; in the tests of the progress output we won't use values that don't fit into an int anyway. [1] start_progress() expects the total number as an uint64_t, that's why I chose the same type when declaring the variable holding the value given on the command line. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> [jpag: Debian unstable/ppc64 (big-endian)] Tested-By: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> [tz: Fedora s390x (big-endian)] Tested-By: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18completion: clarify installation instruction for zshLibravatar Maxim Belsky1-2/+3
The original comment does not describe type of ~/.zsh/_git explicitly and zsh does not warn or fail if a user create it as a dictionary. So unexperienced users could be misled by the original comment. There is a small update to clarify it. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Maxim Belsky <public.belsky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18Git 2.24-rc0Libravatar Junio C Hamano2-1/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18Merge branch 'rs/remote-curl-use-argv-array'Libravatar Junio C Hamano1-13/+9
Code cleanup. * rs/remote-curl-use-argv-array: remote-curl: use argv_array in parse_push()
2019-10-18Merge branch 'rs/column-use-utf8-strnwidth'Libravatar Junio C Hamano1-12/+1
Code cleanup. * rs/column-use-utf8-strnwidth: column: use utf8_strnwidth() to strip out ANSI color escapes
2019-10-18Merge branch 'rs/http-push-simplify'Libravatar Junio C Hamano1-4/+4
Code cleanup. * rs/http-push-simplify: http-push: simplify deleting a list item
2019-10-18Merge branch 'jj/stash-reset-only-toplevel'Libravatar Junio C Hamano3-3/+43
"git stash save" lost local changes to submodules, which has been corrected. * jj/stash-reset-only-toplevel: stash: avoid recursive hard reset on submodules
2019-10-18Merge branch 'bw/format-patch-o-create-leading-dirs'Libravatar Junio C Hamano4-2/+42
"git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>" not "mkdir -p <outdir>", which is being corrected. * bw/format-patch-o-create-leading-dirs: format-patch: create leading components of output directory
2019-10-18Merge branch 'bb/compat-util-comment-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * bb/compat-util-comment-fix: git-compat-util: fix documentation syntax
2019-10-18Merge branch 'bb/utf8-wcwidth-cleanup'Libravatar Junio C Hamano1-4/+2
Code cleanup. * bb/utf8-wcwidth-cleanup: utf8: use ARRAY_SIZE() in git_wcwidth()
2019-10-18Merge branch 'dl/allow-running-cocci-verbosely'Libravatar Junio C Hamano1-1/+2
Dev support update. * dl/allow-running-cocci-verbosely: Makefile: respect $(V) in %.cocci.patch target
2019-10-18Merge branch 'dl/compat-cleanup'Libravatar Junio C Hamano1-1/+1
Code formatting micronit fix. * dl/compat-cleanup: pthread.h: manually align parameter lists
2019-10-18Merge branch 'ta/t1308-typofix'Libravatar Junio C Hamano1-4/+4
Test fix. * ta/t1308-typofix: t1308-config-set: fix a test that has a typo
2019-10-18Merge branch 'js/doc-stash-save'Libravatar Junio C Hamano1-2/+3
Doc clarification. * js/doc-stash-save: doc(stash): clarify the description of `save`
2019-10-18grep: avoid leak of chartables in PCRE2Libravatar Carlo Marcelo Arenas Belón2-3/+5
94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) introduced a small memory leak visible with valgrind in t7813. Complete the creation of a PCRE2 specific variable that was missing from the original change and free the generated table just like it is done for PCRE1. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18grep: make PCRE2 aware of custom allocatorLibravatar Carlo Marcelo Arenas Belón3-1/+35
94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include a way to override the system allocator, and so it is incompatible with custom allocators (e.g. nedmalloc). This problem became obvious when we tried to plug a memory leak by `free()`ing a data structure allocated by PCRE2, triggering a segfault in Windows (where we use nedmalloc by default). PCRE2 requires the use of a general context to override the allocator and therefore, there is a lot more code needed than in PCRE1, including a couple of wrapper functions. Extend the grep API with a "destructor" that could be called to cleanup any objects that were created and used globally. Update `builtin/grep.c` to use that new API, but any other future users should make sure to have matching `grep_init()`/`grep_destroy()` calls if they are using the pattern matching functionality. Move some of the logic that was before done per thread (in the workers) into an earlier phase to avoid degrading performance, but as the use of PCRE2 with custom allocators is better understood it is expected more of its functions will be instructed to use the custom allocator as well as was done in the original code[1] this work was based on. [1] https://public-inbox.org/git/3397e6797f872aedd18c6d795f4976e1c579514b.1565005867.git.gitgitgadget@gmail.com/ Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18grep: make PCRE1 aware of custom allocatorLibravatar Carlo Marcelo Arenas Belón1-0/+8
63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) didn't include a way to override the system alocator, and so it is incompatible with USE_NED_ALLOCATOR as reported by Dscho[1] (in similar code from PCRE2) Note that nedmalloc, as well as other custom allocators like jemalloc and mi-malloc, can be configured at runtime (via `LD_PRELOAD`), therefore we cannot know at compile time whether a custom allocator is used or not. Make the minimum change possible to ensure this combination is supported by extending `grep_init()` to set the PCRE1 specific functions to Git's idea of `malloc()` and `free()` and therefore making sure all allocations are done inside PCRE1 with the same allocator than the rest of Git. This change has negligible performance impact: PCRE needs to allocate memory once per program run for the character table and for each pattern compilation. These are both rare events compared to matching patterns against lines. Actual measurements[2] show that the impact is lost in the noise. [1] https://public-inbox.org/git/pull.306.git.gitgitgadget@gmail.com [2] https://public-inbox.org/git/7f42007f-911b-c570-17f6-1c6af0429586@web.de Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-17remote-curl: pass on atomic capability to remote sideLibravatar brian m. carlson5-3/+62
When pushing more than one reference with the --atomic option, the server is supposed to perform a single atomic transaction to update the references, leaving them either all to succeed or all to fail. This works fine when pushing locally or over SSH, but when pushing over HTTP, we fail to pass the atomic capability to the remote side. In fact, we have not reported this capability to any remote helpers during the life of the feature. Now normally, things happen to work nevertheless, since we actually check for most types of failures, such as non-fast-forward updates, on the client side, and just abort the entire attempt. However, if the server side reports a problem, such as the inability to lock a ref, the transaction isn't atomic, because we haven't passed the appropriate capability over and the remote side has no way of knowing that we wanted atomic behavior. Fix this by passing the option from the transport code through to remote helpers, and from the HTTP remote helper down to send-pack. With this change, we can detect if the server side rejects the push and report back appropriately. Note the difference in the messages: the remote side reports "atomic transaction failed", while our own checking rejects pushes with the message "atomic push failed". Document the atomic option in the remote helper documentation, so other implementers can implement it if they like. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15diff-highlight: fix a whitespace nitLibravatar Norman Rasmussen1-1/+1
This changes the indent from "<tab><sp><sp><sp><sp><sp><sp><sp><sp>" to "<tab><tab>" so that the statement lines up with the rest of the block. Signed-off-by: Norman Rasmussen <norman@rasmussen.co.za> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15Ninth batchLibravatar Junio C Hamano1-0/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15Merge branch 'jk/coc'Libravatar Junio C Hamano1-0/+93
Code-of-conduct document. * jk/coc: CODE_OF_CONDUCT: mention individual project-leader emails add a Code of Conduct document
2019-10-15Merge branch 'js/trace2-fetch-push'Libravatar Junio C Hamano4-10/+41
Dev support. * js/trace2-fetch-push: transport: push codepath can take arbitrary repository push: add trace2 instrumentation fetch: add trace2 instrumentation
2019-10-15Merge branch 'jt/push-avoid-lazy-fetch'Libravatar Junio C Hamano1-1/+2
Performance hack. * jt/push-avoid-lazy-fetch: send-pack: never fetch when checking exclusions
2019-10-15Merge branch 'dl/format-patch-doc-test-cleanup'Libravatar Junio C Hamano1-2/+3
test cleanup. * dl/format-patch-doc-test-cleanup: t4014: treat rev-list output as the expected value
2019-10-15Merge branch 'js/xdiffi-comment-updates'Libravatar Junio C Hamano1-44/+55
Comment update. * js/xdiffi-comment-updates: xdiffi: fix typos and touch up comments
2019-10-15Merge branch 'dl/t0000-skip-test-test'Libravatar Junio C Hamano1-0/+38
test update. * dl/t0000-skip-test-test: t0000: cover GIT_SKIP_TESTS blindspots
2019-10-15Merge branch 'tg/range-diff-output-update'Libravatar Junio C Hamano3-22/+92
"git range-diff" failed to handle mode-only change, which has been corrected. * tg/range-diff-output-update: range-diff: don't segfault with mode-only changes
2019-10-15Merge branch 'gs/sq-quote-buf-pretty'Libravatar Junio C Hamano2-0/+13
Pretty-printed command line formatter (used in e.g. reporting the command being run by the tracing API) had a bug that lost an argument that is an empty string, which has been corrected. * gs/sq-quote-buf-pretty: sq_quote_buf_pretty: don't drop empty arguments
2019-10-15Merge branch 'ew/hashmap'Libravatar Junio C Hamano31-381/+667
Code clean-up of the hashmap API, both users and implementation. * ew/hashmap: hashmap_entry: remove first member requirement from docs hashmap: remove type arg from hashmap_{get,put,remove}_entry OFFSETOF_VAR macro to simplify hashmap iterators hashmap: introduce hashmap_free_entries hashmap: hashmap_{put,remove} return hashmap_entry * hashmap: use *_entry APIs for iteration hashmap_cmp_fn takes hashmap_entry params hashmap_get{,_from_hash} return "struct hashmap_entry *" hashmap: use *_entry APIs to wrap container_of hashmap_get_next returns "struct hashmap_entry *" introduce container_of macro hashmap_put takes "struct hashmap_entry *" hashmap_remove takes "const struct hashmap_entry *" hashmap_get takes "const struct hashmap_entry *" hashmap_add takes "struct hashmap_entry *" hashmap_get_next takes "const struct hashmap_entry *" hashmap_entry_init takes "struct hashmap_entry *" packfile: use hashmap_entry in delta_base_cache_entry coccicheck: detect hashmap_entry.hash assignment diff: use hashmap_entry_init on moved_entry.ent
2019-10-15Merge branch 'js/trace2-cap-max-output-files'Libravatar Junio C Hamano11-28/+184
The trace2 output, when sending them to files in a designated directory, can populate the directory with too many files; a mechanism is introduced to set the maximum number of files and discard further logs when the maximum is reached. * js/trace2-cap-max-output-files: trace2: write discard message to sentinel files trace2: discard new traces if target directory has too many files docs: clarify trace2 version invariants docs: mention trace2 target-dir mode in git-config
2019-10-15Merge branch 'am/t0028-utf16-tests'Libravatar Junio C Hamano1-1/+40
Test fixes. * am/t0028-utf16-tests: t0028: add more tests t0028: fix test for UTF-16-LE-BOM
2019-10-15Merge branch 'dl/octopus-graph-bug'Libravatar Junio C Hamano2-27/+308
"git log --graph" for an octopus merge is sometimes colored incorrectly, which is demonstrated and documented but not yet fixed. * dl/octopus-graph-bug: t4214: demonstrate octopus graph coloring failure t4214: explicitly list tags in log t4214: generate expect in their own test cases t4214: use test_merge test-lib: let test_merge() perform octopus merges
2019-10-15Merge branch 'en/fast-imexport-nested-tags'Libravatar Junio C Hamano6-38/+266
Updates to fast-import/export. * en/fast-imexport-nested-tags: fast-export: handle nested tags t9350: add tests for tags of things other than a commit fast-export: allow user to request tags be marked with --mark-tags fast-export: add support for --import-marks-if-exists fast-import: add support for new 'alias' command fast-import: allow tags to be identified by mark labels fast-import: fix handling of deleted tags fast-export: fix exporting a tag and nothing else
2019-10-15Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano14-33/+430
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-15Merge branch 'gs/commit-graph-trace-with-cmd'Libravatar Junio C Hamano1-0/+6
Dev support. * gs/commit-graph-trace-with-cmd: commit-graph: emit trace2 cmd_mode for each sub-command
2019-10-15Merge branch 'js/fetch-jobs'Libravatar Junio C Hamano4-21/+137
"git fetch --jobs=<n>" allowed <n> parallel jobs when fetching submodules, but this did not apply to "git fetch --multiple" that fetches from multiple remote repositories. It now does. * js/fetch-jobs: fetch: let --jobs=<n> parallelize --multiple, too
2019-10-15Merge branch 'en/merge-recursive-cleanup'Libravatar Junio C Hamano12-334/+736
The merge-recursive machiery is one of the most complex parts of the system that accumulated cruft over time. This large series cleans up the implementation quite a bit. * en/merge-recursive-cleanup: (26 commits) merge-recursive: fix the fix to the diff3 common ancestor label merge-recursive: fix the diff3 common ancestor label for virtual commits merge-recursive: alphabetize include list merge-recursive: add sanity checks for relevant merge_options merge-recursive: rename MERGE_RECURSIVE_* to MERGE_VARIANT_* merge-recursive: split internal fields into a separate struct merge-recursive: avoid losing output and leaking memory holding that output merge-recursive: comment and reorder the merge_options fields merge-recursive: consolidate unnecessary fields in merge_options merge-recursive: move some definitions around to clean up the header merge-recursive: rename merge_options argument to opt in header merge-recursive: rename 'mrtree' to 'result_tree', for clarity merge-recursive: use common name for ancestors/common/base_list merge-recursive: fix some overly long lines cache-tree: share code between functions writing an index as a tree merge-recursive: don't force external callers to do our logging merge-recursive: remove useless parameter in merge_trees() merge-recursive: exit early if index != head Ensure index matches head before invoking merge machinery, round N merge-recursive: remove another implicit dependency on the_repository ...
2019-10-15remote-curl: use argv_array in parse_push()Libravatar René Scharfe1-13/+9
Use argv_array to build an array of strings instead of open-coding it. This simplifies the code a bit. We also need to make the specs parameter of push(), push_dav() and push_git() const to match the argv member of the argv_array. That's fine, as all three only actually read from the specs array anyway. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>