tests


Log

Author Commit Date CI Message
Edward Thomson 219512e7 2018-07-20T14:14:16 buf tests: allocate a smaller size for the oom On Linux (where we run valgrind) allocate a smaller buffer, but still an insanely large size. This will cause malloc to fail but will not cause valgrind to report a likely error with a negative-sized malloc. Keep the original buffer size on non-Linux platforms: this is well-tested on them and changing it may be problematic. On macOS, for example, using the new size causes `malloc` to print a warning to stderr.
Edward Thomson ce798b25 2018-07-04T10:56:56 tests: simplify cmake test configuration Simplify the names for the tests, removing the unnecessary "libgit2-clar" prefix. Make "all" the new default test run, and include the online tests by default (since HTTPS should always be enabled). For the CI tests, create an offline-only test, then the various online tests.
Edward Thomson d285de73 2018-07-20T21:52:24 push tests: deeply free the specs Don't just free the spec vector, also free the specs themselves.
Edward Thomson dad99881 2018-07-20T21:51:36 push tests: deeply free the push status Don't just free the push status structure, actually free the strings that were strdup'd into the struct as well.
Patrick Steinhardt 0652abaa 2018-07-20T12:56:49 Merge pull request #4702 from tiennou/fix/coverity Assorted Coverity fixes
Patrick Steinhardt e1a4a8eb 2018-06-25T11:58:34 cmake: enforce C90 standard While the aim of libgit2 was to conform to C90 code, we never instructed the compiler to enforce C90 compliance. Thus, quite a few violations were able to get into our code base, which have been removed with the previous commits. As we are now able to build libgit2 with C90 enforced, we can set the C_STANDARD property for our own build targets. Note that we explicitly avoid setting the C standard for our third-party dependencies. At least the zlib target does not build with C90 enforced, and we do not want to fix them by deviating from upstream. Thus we simply enforce no standard for them.
Patrick Steinhardt c13e56f9 2018-06-25T14:12:53 cmake: distinguish internal and system include directories While we want to enforce strict C90 mode, this may cause issues with system provided header files which are themselves not strictly conforming. E.g. if a system header has C++ style comments, a compiler in strict C90 mode would produce an error and abort the build. As the user most likely doesn't want to change the system header, this would completely break the build on such systems. One example of this is mbedtls, which provides such header files. The problem can be worked around by distinguishing between system-provided and project-provided include directories. When adding include directories via "-isystem" instead of "-I", the compiler will skip certain checks and print out less warnings. To use system includes, we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and `TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the include directories into two variables because of this, as we definitely still want to check for all warnings produced by our own header files.
Patrick Steinhardt 9994cd3f 2018-06-25T11:56:52 treewide: remove use of C++ style comments C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Edward Thomson 6dfc8bc2 2018-07-09T23:10:05 Merge pull request #4719 from pks-t/pks/delta-oob Delta OOB access
Etienne Samson 89091d36 2018-07-06T20:24:21 tests: fix a relative pathname issue The path given to `git_index_add_bypath` is relative to the root of the repository. That `describe/file` path is relative to the root of the sandbox directory, hence if I add the missing `cl_git_pass` I rightfully get an error that `$SANDBOX/describe/describe/file doesn't exist`. The path is thus changed to be made relative to the repository, which makes the failure go away and "restore" the test.
Etienne Samson 8455a270 2018-07-01T12:04:27 tests: add missing cl_git_pass to tests Reported by Coverity, CID 1393678-1393697.
Etienne Samson 17bd3b96 2018-06-19T20:15:49 tests: mailmap/parsing: add a missing cl_git_pass Reported by Coverity, CID 1393483
Edward Thomson f4633791 2018-07-06T12:36:05 Merge pull request #4687 from tiennou/fix/4672 patch_parse: populate line numbers while parsing diffs
Patrick Steinhardt f2a1cece 2018-07-06T11:25:47 Merge pull request #4686 from tiennou/fix/more-worktree-from-bare Fix git_worktree_validate failing on bare repositories
Patrick Steinhardt 8a00de08 2018-07-06T10:47:06 Merge pull request #4699 from nelhage/fetch-null-dst git_refspec_transform: Handle NULL dst
Edward Thomson c43658f6 2018-06-30T13:24:23 Merge pull request #4536 from libgit2/ethomson/index_dirty Add a "dirty" state to the index when it has unsaved changes
Nelson Elhage ff8edac9 2018-06-29T16:18:36 formatting fix
Edward Thomson bfa1f022 2018-06-22T19:17:08 settings: optional unsaved index safety Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause commands that reload the on-disk index to fail if the current `git_index` has changed that have not been saved. This will prevent users from - for example - adding a file to the index then calling a function like `git_checkout` and having that file be silently removed from the index since it was re-read from disk. Now calls that would re-read the index will fail if the index is "dirty", meaning changes have been made to it but have not been written. Users can either `git_index_read` to discard those changes explicitly, or `git_index_write` to write them.
Edward Thomson 787768c2 2018-06-22T19:07:54 index: return a unique error code on dirty index When the index is dirty, return GIT_EINDEXDIRTY so that consumers can identify the exact problem programatically.
Edward Thomson 5e26391a 2018-06-18T18:28:08 checkout: FORCE doesn't halt on dirty index If the index is dirty, allow `GIT_CHECKOUT_FORCE` to obliterate unsaved changes. This is in keeping with its name and description.
Edward Thomson b242cdbf 2017-11-17T00:19:07 index: commit the changes to the index properly Now that the index has a "dirty" state, where it has changes that have not yet been committed or rolled back, our tests need to be adapted to actually commit or rollback the changes instead of assuming that the index can be operated on in its indeterminate state.
Edward Thomson dc4a18c7 2017-11-12T08:23:13 index: test dirty index bit Test that any changes to the index will mark the index as dirty. Also ensure that when we initialize a new index, read the index contents from disk, or write the index contents to disk that we reset the dirty flag to zero. Further ensure that an unforced read with dirty contents (when the on-disk index has not changed) does _not_ reset the dirty flag as we have not updated the contents of our index and our unsaved contents remain intact.
Edward Thomson 55a96606 2018-06-18T16:14:26 checkout tests: validate GIT_CHECKOUT_NO_REFRESH Add tests that ensure that we re-read the on-disk image by default during checkout, but when the `GIT_CHECKOUT_NO_REFRESH` option is specified, we do _not_ re-read the index.
Etienne Samson 8356bf7e 2018-06-29T14:39:14 tests: worktree/bare: test some paths
Etienne Samson d0921127 2018-06-29T14:39:13 tests: add a helper to build sandbox subpaths quickly
Etienne Samson 83c35f7e 2018-06-29T14:39:11 tests: worktree/bare: fix git_worktree_validate
Etienne Samson bd40f0d7 2018-06-29T14:39:10 tests: worktree/bare: check git_worktree_list
Etienne Samson 7e3c13e0 2018-06-29T14:39:08 tests: worktree/bare: gather all tests
Patrick Steinhardt af3088e4 2018-06-29T11:45:15 refspec: rename `git_refspec__free` to `git_refspec__dispose` Since commit 630a67366 (refspec: add public parsing api, 2018-02-07), we now have two functions `git_refspec_free` and `git_refspec__free`. The difference is that the first one will free the structure itself, while the second one will only free the structure's contents. Use our new `dispose` naming pattern for the latter function to help avoid confusion.
Patrick Steinhardt 7192e26f 2018-06-29T09:43:33 Merge pull request #4519 from cynecx/refspec-parsing refspec: add public parsing api
Patrick Steinhardt 24597812 2018-06-29T09:11:02 delta: fix out-of-bounds read of delta When computing the offset and length of the delta base, we repeatedly increment the `delta` pointer without checking whether we have advanced past its end already, which can thus result in an out-of-bounds read. Fix this by repeatedly checking whether we have reached the end. Add a test which would cause Valgrind to produce an error. Reported-by: Riccardo Schirone <rschiron@redhat.com> Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
Patrick Steinhardt 7db25870 2018-06-29T07:45:18 delta: fix sign-extension of big left-shift Our delta code was originally adapted from JGit, which itself adapted it from git itself. Due to this heritage, we inherited a bug from git.git in how we compute the delta offset, which was fixed upstream in 48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As explained by Linus: Shifting 'unsigned char' or 'unsigned short' left can result in sign extension errors, since the C integer promotion rules means that the unsigned char/short will get implicitly promoted to a signed 'int' due to the shift (or due to other operations). This normally doesn't matter, but if you shift things up sufficiently, it will now set the sign bit in 'int', and a subsequent cast to a bigger type (eg 'long' or 'unsigned long') will now sign-extend the value despite the original expression being unsigned. One example of this would be something like unsigned long size; unsigned char c; size += c << 24; where despite all the variables being unsigned, 'c << 24' ends up being a signed entity, and will get sign-extended when then doing the addition in an 'unsigned long' type. Since git uses 'unsigned char' pointers extensively, we actually have this bug in a couple of places. In our delta code, we inherited such a bogus shift when computing the offset at which the delta base is to be found. Due to the sign extension we can end up with an offset where all the bits are set. This can allow an arbitrary memory read, as the addition in `base_len < off + len` can now overflow if `off` has all its bits set. Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned integer again. Add a test with a crafted delta that would actually succeed with an out-of-bounds read in case where the cast wouldn't exist. Reported-by: Riccardo Schirone <rschiron@redhat.com> Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
Edward Thomson 7330ae67 2018-06-26T10:45:57 index::addall tests: write the index When running `git_index_add_all`, we should write the index to disk so that we can re-read it safely during status.
Edward Thomson 08ea0d7d 2018-02-18T11:49:08 index::reuc tests: test that checkout succeeds The index::reuc tests must test that the checkout itself succeeds, otherwise subsequent tests are not valid. In fact, the checkouts were failing because when checking out `SAFE`, they cannot update the files that are in conflict. Change the checkout level to `FORCE` to ensure that they get updated correctly.
Edward Thomson c4ce017f 2018-02-18T22:27:34 index::names tests: add conflicts with high stages We add entries into the main index to correspond with the NAME entries that we're going to test. NAME entries store the results of conflicts occuring with rename detection during merge, and they must correspond to conflicts in the index. This test was mistakenly adding regular entries. The checkout validation failed, since it requires NAME entries to correspond to high-stage (conflict) entries. Correct the test to actually create conflicts.
Nelson Elhage 46c9f26f 2018-06-25T15:47:31 Add a test. Verified that this breaks before the fix and passes afterwards.
Nika Layzell 4fd81c53 2018-06-18T19:43:53 Clear revwalk sorting when resetting Currently we fail to clear the sorting flag for revwalks when resetting. This caused a poor interaction with the limited flag during a recent patch. This patch clears the revwalk sorting flag and causes it to no longer persist over resets.
cynecx 630a6736 2018-02-07T22:30:27 refspec: add public parsing api Fix typo Fix some type issues More fixes Address requested changes Add test Fix naming Fix condition and tests Address requested changes Fix typo
Etienne Samson f9e28026 2018-06-18T20:37:18 patch_parse: populate line numbers while parsing diffs
Sven Strickroth b5818dda 2018-06-18T13:05:08 Fix last references to deprecated git_buf_free Signed-off-by: Sven Strickroth <email@cs-ware.de>
Nika Layzell f98131be 2018-06-17T00:40:25 Require the length argument to git_mailmap_from_buffer and make mailmap_add_buffer internal
Nika Layzell 9faf36a6 2018-06-14T22:48:58 mailmap: git_buf_free => git_buf_dispose
Nika Layzell 56303e1a 2018-05-07T11:59:00 mailmap: API and style cleanup
Nika Layzell a140c138 2018-04-08T03:01:37 mailmap: Updates tests for new API and features
Nika Layzell 18ff9bab 2018-03-27T22:48:03 mailmap: API and style cleanup
Nika Layzell 57cfeab9 2018-03-26T15:05:37 mailmap: Switch mailmap parsing to use the git_parse module
Nika Layzell aa3a24a4 2018-03-26T14:44:15 mailmap: Clean up the mailmap fixture's .gitted directory
Emilio Cobos Álvarez 5c6c8a9b 2018-03-18T01:26:30 mailmap: Fix some other minor style nits
Nika Layzell 4ff44be8 2018-03-17T18:24:15 mailmap: Fix more bugs which snuck in when I rebased
Nika Layzell 983b8c2d 2018-03-17T18:15:41 mailmap: Add a bunch of tests for the new mailmap functionality
Nika Layzell 939d8d57 2018-03-17T18:14:03 mailmap: Support path fixtures in cl_git_repository_init()
Emilio Cobos Álvarez b88cbf8c 2018-03-18T01:40:47 mailmap: Add some super-basic tests
Edward Thomson 3be73011 2018-06-11T18:26:22 Merge pull request #4436 from pks-t/pks/packfile-stream-free pack: rename `git_packfile_stream_free`
Edward Thomson 96212813 2018-06-11T17:11:36 stash test: free the commit
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Edward Thomson 123f01f0 2018-06-10T12:21:43 stash test: free the reference
Edward Thomson 795a5b28 2018-06-09T18:36:21 Merge pull request #4668 from novalis/bad-stash Fix stash save bug with fast path index check
Edward Thomson 44788c96 2018-06-09T18:00:23 Merge pull request #4662 from pks-t/pks/gitfile-api path: unify `git_path_is_*` APIs
Edward Thomson bc0f3227 2018-06-09T17:59:46 Merge pull request #4670 from pks-t/pks/ignore-leadingdir Fix negative gitignore rules with leading directories
Patrick Steinhardt 9865cd16 2018-03-20T14:23:49 alloc: make memory allocators use function pointers Currently, our memory allocators are being redirected to the correct implementation at compile time by simply using macros. In order to make them swappable at runtime, this commit reshuffles that by instead making use of a global "git_allocator" structure, whose pointers are set up to reference the allocator functions. Like this, it becomes easy to swap out allocators by simply setting these function pointers. In order to initialize a "git_allocator", our provided allocators "stdalloc" and "crtdbg" both provide an init function. This is being called to initialize a passed in allocator struct and set up its members correctly. No support is yet included to enable users of libgit2 to switch out the memory allocator at a global level.
David Turner 5a7d454b 2018-06-04T12:56:08 Fix stash save bug with fast path index check If the index contains stat data for a modified file, and the file is not racily dirty, and there exists an untracked working tree directory alphabetically after that file, and there are no other changes to the repo, then git_stash_save would fail. It would confuse the untracked working tree directory for the modified file, because they have the same sha: zero. The wt directory has a sha of zero because it's a directory, and the file would have a zero sha because we wouldn't read the file -- we would just know that it doesn't match the index. To fix this confusion, we simply check mode as well as SHA.
Patrick Steinhardt 20306d36 2018-06-06T14:31:28 Merge pull request #4665 from neithernut/fix-refdb-glob refdb_fs: fix regression: failure when globbing for non-existant references
Patrick Steinhardt 8178c70f 2018-06-06T09:23:01 tests: submodule: do not rely on config iteration order The test submodule::lookup::duplicated_path, which tries to verify that we detect submodules with duplicated paths, currently relies on the gitmodules file of "submod2_target". While this file has two gitmodules with the same path, one of these gitmodules has an empty name and thus does not pass `git_submodule_name_is_valid`. Because of this, the test is in fact dependent on the iteration order in which we process the submodules. In fact the "valid" submodule comes first, the "invalid" submodule will cause the desired error. In fact the "invalid" submodule comes first, it will be skipped due to its name being invalid, and we will not see the desired error. While this works on the master branch just right due to the refactoring of our config code, where iteration order is now deterministic, this breaks on all older maintenance branches. Fix the issue by simply using `cl_git_rewritefile` to rewrite the gitmodules file. This greatly simplifies the test and also makes the intentions of it much clearer.
Patrick Steinhardt 20b4c175 2018-06-05T16:12:58 ignore: fix negative leading directory rules unignoring subdirectory files When computing whether a file is ignored, we simply search for the first matching rule and return whether it is a positive ignore rule (the file is really ignored) or whether it is a negative ignore rule (the file is being unignored). Each rule has a set of flags which are being passed to `fnmatch`, depending on what kind of rule it is. E.g. in case it is a negative ignore we add a flag `GIT_ATTR_FNMATCH_NEGATIVE`, in case it contains a glob we set the `GIT_ATTR_FNMATCH_HASGLOB` flag. One of these flags is the `GIT_ATTR_FNMATCH_LEADINGDIR` flag, which is always set in case the pattern has a trailing "/*" or in case the pattern is negative. The flag causes the `fnmatch` function to return a match in case a string is a leading directory of another, e.g. "dir/" matches "dir/foo/bar.c". In case of negative patterns, this is wrong in certain cases. Take the following simple example of a gitignore: dir/ !dir/ The `LEADINGDIR` flag causes "!dir/" to match "dir/foo/bar.c", and we correctly unignore the directory. But take this example: *.test !dir/* We expect everything in "dir/" to be unignored, but e.g. a file in a subdirectory of dir should be ignored, as the "*" does not cross directory hierarchies. With `LEADINGDIR`, though, we would just see that "dir/" matches and return that the file is unignored, even if it is contained in a subdirectory. Instead, we want to ignore leading directories here and check "*.test". Afterwards, we have to iterate up to the parent directory and do the same checks. To fix the issue, disallow matching against leading directories in gitignore files. This can be trivially done by just adding the `GIT_ATTR_FNMATCH_NOLEADINGDIR` to the spec passed to `git_attr_fnmatch__parse`. Due to a bug in that function, though, this flag is being ignored for negative patterns, which is fixed in this commit, as well. As a last fix, we need to ignore rules that are supposed to match a directory when our path itself is a file. All together, these changes fix the described error case.
Patrick Steinhardt 9beb73ed 2018-06-05T16:45:23 tests: status::ignore: fix style of a test
Julian Ganz d7eca4c3 2018-06-01T08:57:17 refdb_fs: add test for globbing of nonexistant refs
Patrick Steinhardt 92159bd4 2018-05-30T12:18:04 path: unify `git_path_is_*` APIs Right now, there's quite a lot of different function calls to determine whether a path component matches a specific name after normalization from the filesystem. We have a function for each of {gitattributes, gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks. In the long time, this is unmaintainable in case there are e.g. new filesystems with specific semantics, blowing up the number of functions we need to implement. Replace all functions with a simple `git_path_is_gitfile` function, which accepts an enum pointing out the filename that is to be checked against as well as the filesystem normalizations to check for. This greatly simplifies implementation at the expense of the caller having to invoke a somewhat longer function call.
Patrick Steinhardt b2a389c8 2018-05-30T08:35:06 submodule: detect duplicated submodule paths When loading submodule names, we build a map of submodule paths and their respective names. While looping over the configuration keys, we do not check though whether a submodule path was seen already. This leads to a memory leak in case we have multiple submodules with the same path, as we just overwrite the old value in the map in that case. Fix the error by verifying that the path to be added is not yet part of the string map. Git does not allow to have multiple submodules for a path anyway, so we now do the same and detect this duplication, reporting it to the user.
Carlos Martín Nieto 7f6c1ce9 2018-05-29T21:04:39 Merge pull request #4660 from libgit2/cmn/submodule-traversal Fixes for CVE 2018-11235
Carlos Martín Nieto 57e343d7 2018-05-24T21:58:40 path: hand-code the zero-width joiner as UTF-8
Carlos Martín Nieto 9e723db8 2018-05-24T20:28:36 submodule: plug leaks from the escape detection
Carlos Martín Nieto 3fbfae26 2018-05-22T20:37:23 checkout: change symlinked .gitmodules file test to expect failure When dealing with `core.proectNTFS` and `core.protectHFS` we do check against `.gitmodules` but we still have a failing test as the non-filesystem codepath does not check for it.
Carlos Martín Nieto a7168b47 2018-05-22T16:13:47 path: reject .gitmodules as a symlink Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
Carlos Martín Nieto 02c80ad7 2018-05-22T15:21:08 path: accept the name length as a parameter We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.
Carlos Martín Nieto a145f2b6 2018-05-22T14:16:45 checkout: add a failing test for refusing a symlinked .gitmodules We want to reject these as they cause compatibility issues and can lead to git writing to files outside of the repository.
Carlos Martín Nieto 177dcfc7 2018-05-18T15:16:53 path: hide the dotgit file functions These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.
Carlos Martín Nieto 9de97ae7 2018-05-16T15:42:08 path: add a function to detect an .gitmodules file Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.
Carlos Martín Nieto 397abe98 2018-05-14T16:03:15 submodule: also validate Windows-separated paths for validity Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to protect Windows users. Ideally we would check for both separators without the need for the copied string, but this'll get us over the RCE.
Carlos Martín Nieto 6b15ceac 2018-04-30T13:47:15 submodule: ignore submodules which include path traversal in their name If the we decide that the "name" of the submodule (i.e. its path inside `.git/modules/`) is trying to escape that directory or otherwise trick us, we ignore the configuration for that submodule. This leaves us with a half-configured submodule when looking it up by path, but it's the same result as if the configuration really were missing. The name check is potentially more strict than it needs to be, but it lets us re-use the check we're doing for the checkout. The function that encapsulates this logic is ready to be exported but we don't want to do that in a security release so it remains internal for now.
Patrick Steinhardt f9cf9a04 2018-05-09T14:51:57 Merge pull request #4642 from pks-t/pks/cmake-resolve-pkgconfig cmake: resolve libraries found by pkg-config
Patrick Steinhardt 6c2939d6 2018-05-09T13:57:17 Merge pull request #4646 from pks-t/pks/gcc-8.1-warnings Fix GCC 8.1 warnings
Patrick Steinhardt 8ab470f5 2018-04-27T15:31:43 cmake: remove now-useless LIBGIT2_LIBDIRS handling With the recent change of always resolving pkg-config libraries to their full path, we do not have to manage the LIBGIT2_LIBDIRS variable anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp, which is a CMake-style library target and can thus be resolved by CMake automatically. Remove the variable to simplify our build system a bit.
Etienne Samson a82082d0 2018-04-20T08:38:50 worktree: a worktree can be made from a bare repository
Patrick Steinhardt bb468ada 2018-05-07T13:44:15 Merge pull request #4542 from stanhu/sh-sanitize-utf8-hunk-header Sanitize the hunk header to ensure it contains UTF-8 valid data
Stan Hu 9d83a2b0 2018-02-22T22:55:50 Sanitize the hunk header to ensure it contains UTF-8 valid data The diff driver truncates the hunk header text to 80 bytes, which can truncate 4-byte Unicode characters and introduce garbage characters in the diff output. This change sanitizes the hunk header before it is displayed. This mirrors the test in git: https://github.com/git/git/blob/master/t/t4025-hunk-header.sh Closes https://github.com/libgit2/rugged/issues/716
Patrick Steinhardt 1bf57b5a 2018-05-04T15:27:11 tests: iterator::workdir: fix GCC warning Since GCC 8.1, the compiler performs some bounds checking when copying static data into arrays with a known size. In one test, we print a format string of "%s/sub%02d" into a buffer of 64 bytes. The input buffer for the first "%s" is bounded to at most 63 characters, plus four bytes for the static string "/sub" plus two more bytes for "%02d". Thus, our target buffer needs to be at least 70 bytes in size, including the NUL byte. There seems to be a bug in the analysis, though, because GCC will not account for the limiting "%02" prefix, treating it as requiring the same count of bytes as a "%d". Thus, we end up at 79 bytes that are required to fix the warning. To make it look nicer and less special, we just round the buffer size up to 80 bytes.
Patrick Steinhardt 0750d0cc 2018-05-04T15:25:22 tests: refs::normalize: simplify code to avoid GCC warning Since version 8.1, GCC will do some automatic bounds checking when printing static content into a buffer with known size. The bounds checking doesn't yet work quite right in all scenarios and may thus lead to false positives. Fix one of these false positives in refs::normalize by simplifying the code.
Carlos Martín Nieto 7553763a 2018-04-30T13:03:44 submodule: add a failing test for a submodule escaping .git/modules We should pretend such submdules do not exist as it can lead to RCE.
Patrick Steinhardt b33b6d33 2018-04-30T09:27:47 Merge pull request #4640 from mkeeler/worktree-convenience2 worktree: add functions to get name and path
Patrick Steinhardt 5ace1494 2018-04-26T11:45:38 Merge pull request #4633 from csware/worktree-delereref Fix deletion of unrelated branch on worktree
Matt Keeler 3da1ad20 2018-04-24T17:09:34 worktree: add functions to get name and path
Matt Keeler 45a3b9cd 2018-04-24T17:12:49 tests: fix issue with /tmp paths on macOS[1]
Edward Thomson 86353a72 2018-04-22T14:57:02 Merge pull request #4173 from tiennou/mbedtls mbedTLS support
Edward Thomson 5d346c11 2018-04-22T14:51:00 Merge pull request #4525 from pks-t/pks/config-iterate-in-order Configuration entry iteration in order
Patrick Steinhardt 0ad2372b 2018-04-20T21:25:01 Merge pull request #4636 from tiennou/fix/leaks Fix leaks in master
Patrick Steinhardt 8d138f89 2018-04-20T20:28:48 Merge pull request #4577 from csware/reflog-worktree-head worktree: Read worktree specific reflog for HEAD
Etienne Samson 25100d6d 2018-04-19T19:17:07 tests: free the worktree in add_with_explicit_branch Valgrind log: ==2711== 305 (48 direct, 257 indirect) bytes in 1 blocks are definitely lost in loss record 576 of 624 ==2711== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2711== by 0x5E079E: git__calloc (util.h:99) ==2711== by 0x5E0D21: open_worktree_dir (worktree.c:134) ==2711== by 0x5E0F23: git_worktree_lookup (worktree.c:176) ==2711== by 0x5E1972: git_worktree_add (worktree.c:388) ==2711== by 0x551F23: test_worktree_worktree__add_with_explicit_branch (worktree.c:292) ==2711== by 0x45853E: clar_run_test (clar.c:222) ==2711== by 0x4587E1: clar_run_suite (clar.c:286) ==2711== by 0x458B04: clar_parse_args (clar.c:362) ==2711== by 0x458CAB: clar_test_run (clar.c:428) ==2711== by 0x45665C: main (main.c:24)
Sven Strickroth fd7b5bc3 2018-04-20T12:54:41 Fix deletion of unrelated branch on worktree Signed-off-by: Sven Strickroth <email@cs-ware.de>
Andreas Baumann fac7eac4 2018-04-19T15:21:52 fixed stack smashing due to wrong size of struct stat on the stack on 32-bit systems with 64-bit file descriptor offsets enabled (added -D_FILE_OFFSET_BITS=64 when compiling the test suite)
Edward Thomson 8529ac9b 2018-04-17T23:38:46 Merge pull request #4524 from pks-t/pks/worktree-refs worktree: add ability to create worktree with pre-existing branch