kmx git

Commit	Date	Message
212da30d	2017-09-16T19:49:04	Merge pull request #4348 from pks-t/pks/win32-hash-memleak diff: cleanup hash ctx in `git_diff_patchid`
d378e384	2017-09-15T17:53:01	Merge pull request #4347 from pks-t/pks/appveyor-vs2015 Fix AppVeyor build failures due to CRTDBG linking issue
03a95bc5	2017-09-15T11:32:46	appveyor: add jobs to also build on Visual Studio 2015 In order to cover a wider range of build environments, add two more jobs which build and test libgit2 on Visual Studio 14 2015.
e1076dbf	2017-09-15T10:01:36	appveyor: explicitly specify build images AppVeyor currently does provide three standard build worker images with VS2013, VS2015 and VS2017. Right now, we are using the implicitly, which is the VS2015 one. We want to be more explicit about this, so that we can easily switch build images based on the job. So starting from this commit, we explicitly set the `APPVEYOR_BUILD_WORKER_IMAGE` variable per job, which enables us to choose different images. To be able to test a wider range of build configurations, this commit also switches the jobs for VC2010 over to use the older, VS2013 based images. As the next commit will introduce two new jobs for building with VS2015, we have then covered both build environments. Also, let us be a bit more explicit regarding the CMake generator. Instead of only saying "Visual Studio 10", use the more descriptive value "Visual Studio 10 2010" to at least avoid some confusion surrounding the versioning scheme of Visual Studio.
54214d61	2017-09-15T10:28:32	cmake: fix linker error with dbghelper library When the MSVC_CRTDBG option is set by the developer, we will link in the dbghelper library to enable memory lead detection in MSVC projects. We are doing so by adding it to the variable `CMAKE_C_STANDARD_LIBRARIES`, so that it is linked for every library and executable built by CMake. But this causes our builds to fail with a linker error: ``` LINK: fatal error LNK1104: cannot open file 'advapi32.lib;Dbghelp.lib' ``` The issue here is that we are treating the variable as if it were an array of libraries by setting it via the following command: ``` SET(CMAKE_C_STANDARD_LIBRARIES "${CMAKE_C_STANDARD_LIBRARIES}" "Dbghelp.lib") ``` The generated build commands will then simply stringify the variable, concatenating all the contained libraries with a ";". This causes the observed linking failure. To fix the issue, we should just treat the variabable as a simple string. So instead of adding multiple members, we just add the "Dbghelp.lib" library to the existing string, separated by a space character.
046b081a	2017-09-15T10:46:26	diff: cleanup hash ctx in `git_diff_patchid` After initializing the hash context in `git_diff_patchid`, we never proceed to call `git_hash_ctx_cleanup` on it. While this doesn't really matter on most hash implementations, this causes a memory leak on Win32 due to CNG system requiring a `malloc` call. Fix the memory leak by always calling `git_hash_ctx_cleanup` before exiting.
e098b5f5	2017-09-12T20:21:27	Merge pull request #4344 from slavikus/fix-dirty-buffer-in-git-push-update-tips Clear the remote_ref_name buffer in git_push_update_tips()
71a8204d	2017-09-12T20:20:48	Merge pull request #4346 from pks-t/pks/wo-features-header features.h: allow building without CMake-generated feature header
26f531d3	2017-09-12T13:35:18	features.h: allow building without CMake-generated feature header In commit a390a8464 (cmake: move defines into "features.h" header, 2017-07-01), we have introduced a new "features.h" header. This file is being generated by the CMake build system based on how the libgit2 build has been configured, replacing the preexisting method of simply setting the defines inside of the CMake build system. This was done to help splitting up the build instructions into multiple separate subdirectories. An overlooked shortcoming of this approach is that some projects making use of libgit2 build the library with custom build systems, without making use of CMake. For those users, the introduction of the "features.h" file makes their life harder as they would have to also generate this file. Fix this issue by guarding all inclusions of the generated header file by the `LIBGIT2_NO_FEATURES_H` define. Like this, other build systems can skip the feature header and simply define all used features by specifying `-D` flags for the compiler again.
b34fc3fd	2017-09-11T21:34:41	Clear the remote_ref_name buffer in git_push_update_tips() If fetch_spec was a non-pattern, and it is not the first iteration of push_status vector, then git_refspec_transform would result in the new value appended via git_buf_puts to the previous iteration value. Forcibly clearing the buffer on each iteration to prevent this behavior.
5b947b62	2017-09-10T14:47:04	Merge pull request #4342 from mothacehe/master README: Mention Guile-Git bindings.
b4e0d293	2017-09-09T09:54:58	README: Mention Guile-Git bindings.
3c216453	2017-08-25T21:06:46	Merge pull request #4296 from pks-t/pks/pattern-based-gitignore Fix negative ignore rules with patterns
4b000fc0	2017-08-25T21:05:20	Merge pull request #4305 from pks-t/pks/submodule-with-bare-repo Submodules with bare repo
bcb7e92d	2017-08-25T21:04:04	Merge pull request #4279 from pks-t/pks/error-builds -Werror builds for Travis
477b3e04	2017-07-10T12:25:43	submodule: refuse lookup in bare repositories While it is technically possible to look up submodules inside of a bare repository by reading the submodule configuration of a specific commit, we do not offer this functionality right now. As such, calling both `git_submodule_lookup` and `git_submodule_foreach` should error out early when these functions encounter a bare repository. While `git_submodule_lookup` already does return an error due to not being able to parse the configuration, `git_submodule_foreach` simply returns success and never invokes the callback function. Fix the issue by having both functions check whether the repository is bare and returning an error in that case.
a889c05f	2017-07-10T11:55:33	tests: submodule: add explicit cleanup function in lookup tests
64d1e0b3	2017-07-10T11:52:08	tests: submodule: fix declaration of test The testcase "submodule::lookup::cached" was declared with a single underscore separating the test suide and test name, only. As the clar parser only catches tests with two underscores, it was never executed. Add in the second underscore to actually have it detected and executed.
2d9ff8f5	2017-07-10T09:36:19	ignore: honor case insensitivity for negative ignores When computing negative ignores, we throw away any rule which does not undo a previous rule to optimize. But on case insensitive file systems, we need to keep in mind that a negative ignore can also undo a previous rule with different case, which we did not yet honor while determining whether a rule undoes a previous one. So in the following example, we fail to unignore the "/Case" directory: /case !/Case Make both paths checking whether a plain- or wildcard-based rule undo a previous rule aware of case-insensitivity. This fixes the described issue.
38b44c3b	2017-07-07T17:10:57	tests: status: additional test for negative ignores with pattern This test is by Carlos Martín Nieto.
b8922fc8	2017-07-07T13:27:27	ignore: keep negative rules containing wildcards Ignore rules allow for reverting a previously ignored rule by prefixing it with an exclamation mark. As such, a negative rule can only override previously ignored files. While computing all ignore patterns, we try to use this fact to optimize away some negative rules which do not override any previous patterns, as they won't change the outcome anyway. In some cases, though, this optimization causes us to get the actual ignores wrong for some files. This may happen whenever the pattern contains a wildcard, as we are unable to reason about whether a pattern overrides a previous pattern in a sane way. This happens for example in the case where a gitignore file contains ".c" and "!src/.c", where we wouldn't un-ignore files inside of the "src/" subdirectory. In this case, the first solution coming to mind may be to just strip the "src/" prefix and simply compare the basenames. While that would work here, it would stop working as soon as the basename pattern itself is different, like for example with "x.c" and "!src/.c. As such, we settle for the easier fix of just not optimizing away rules that contain a wildcard.
4467543e	2017-07-07T12:27:43	ignore: return early to avoid useless indentation
9bd83622	2017-07-07T12:27:18	ignore: fix indentation of comment block
414a3384	2017-08-25T17:36:59	travis: error on compiler warnings One of our goals is to have our code free of any warnings. Due to the recent switch to Ubuntu 14.04 on Travis, the last warning regarding some preprocessor-magic in the curl-headers has been fixed and as such, the goal of zero warnings is now reached for Travis CI. In order to avoid introducing new warnings via pull requests, we can now enable building with `-Werror` and turn compiler warnings into errors instead, causing the CI jobs to fail. This build does so by passing the newly introdcued `-DENABLE_WERROR` flag to CMake for all Travis jobs.
175ab8e7	2017-08-25T17:36:24	cmake: add switch to build with -Werror Add a simple switch to enable building with "-Werror=<warning>" instead of "-W<warning". Due to the encapsulated `ENABLE_WARNINGS` macro, this is as simple as adding a new variable "ENABLE_WERROR`, which can be passed on the command line via `-DENABLE_WERROR=ON`. The variable defaults to NO to not bother developers in their day to day work.
4a46a8c1	2017-08-25T17:32:54	cmake: encapsulate enabling/disabling compiler warnings There are multiple sites where we enable or disable compiler warning via "-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism later on to conditionally switch these over to "-Werror=<warning>", we encapsulate the logic into its their own macros `ENABLE_WARNINGS` and `DISABLE_WARNINGS`. Note that we in fact have to use a macro here. Using a function would not modify the CFLAGS inside of the callers scope, but in the function's scope only.
0a93ded1	2017-08-24T21:23:58	Merge pull request #4282 from pks-t/pks/remove-unused-clar-fixtures Split up CMakeLists.txt build instructions
a3a35473	2017-08-17T08:38:47	cmake: fix output location of import libraries and DLLs As observed by Edward Thomson, the libgit2 DLL built by Windows will not end up in the top-level build directory but instead inside of the 'src/' subdirectory. While confusing at first because we are actually setting the LIBRARY_OUTPUT_DIRECTORY to the project's binary directory, the manual page of LIBRARY_OUTPUT_DIRECTORY clears this up: There are three kinds of target files that may be built: archive, library, and runtime. Executables are always treated as runtime targets. Static libraries are always treated as archive targets. Module libraries are always treated as library targets. For non-DLL platforms shared libraries are treated as library targets. For DLL platforms the DLL part of a shared library is treated as a runtime target and the corresponding import library is treated as an archive target. All Windows-based systems including Cygwin are DLL platforms. So in fact, DLLs and import libraries are not treated as libraries at all by CMake but instead as runtime and archive targets. To fix the issue, we can thus simply set the variables RUNTIME_OUTPUT_DIRECTORY and ARCHIVE_OUTPUT_DIRECTORY to the project's root binary directory.
1f43a43d	2017-06-28T13:28:33	cmake: move zlib build instructions into subdirectory Extract code required to build the zlib library into its own CMakeLists.txt, which is included as required.
b7514554	2017-06-28T13:25:09	cmake: move http-parser build instructions into subdirectory Extract code required to build the http-parser library into its own CMakeLists.txt, which is included as required.
9e449e52	2017-06-28T13:23:45	cmake: move regex build instructions into subdirectory Extract code required to build the regex library into its own CMakeLists.txt, which is included as required.
43248500	2017-06-28T13:21:09	cmake: move winhttp build instructions into subdirectory Extract code required to build the winhttp library into its own CMakeLists.txt, which is included as required.
bed7ca3a	2017-06-30T16:57:16	cmake: define WIN_RC with other platform sources This makes splitting up the library build instructions later on more obvious and easier to achieve.
8ee90c39	2017-06-28T13:16:38	cmake: find dependencies after setting build flags This makes splitting up the library build instructions later on more obvious and easier to achieve.
c3635130	2017-06-28T13:14:23	cmake: move definition of Win32 flags together This makes splitting up the library build instructions later on more obvious and easier to achieve.
32a2e500	2017-07-01T13:41:36	cmake: inline TARGET_OS_LIBRARIES function Previous to keeping track of libraries and linking directories via variables, we had two call sites of the `TARGET_OS_LIBRARIES` function to avoid duplicating knowledge on required operating system library dependencies. But as the libgit2_clar target now re-uses defined variables to link against these libraries, we can simply inline the function.
8e31cc25	2017-06-28T12:51:14	cmake: keep track of libraries and includes via lists Later on, we will move detection of required libraries, library directories as well as include directories into a separate CMakeLists.txt file inside of the source directory. Obviously, we want to avoid duplication here regarding these parameters. To prepare for the split, put the parameters into three variables LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the required libraries, linking directory as well as include directories. These variables can later be exported into the parent scope from inside of the source build instructions, making them readily available for the other subdirectories.
dd332e2a	2017-06-23T20:42:41	cmake: use absolute path to deps When refering to files and directories inside of the top-level "deps/" directory, we're being inconsistent in using relative or absolute paths. To enable splitting out parts of the top-level CMakeLists.txt into an own file in the "src/" directory, consistently switch over to use absolute paths to avoid errors when converting.
8341d6cf	2017-07-04T10:57:28	cmake: move regcomp and futimens checks to "features.h" In our CMakeLists.txt, we have to check multiple functions in order to determine if we have to use our own or whether we can use the platform-provided one. For two of these functions, namely `regcomp_l()` and `futimens`, the defined macro is actually used inside of the header file "src/unix/posix.h". As such, these macros are not only required by the library, but also by our test suite, which is makes use of internal headers. To prepare for the CMakeLists.txt split, move these two defines inside of the "features.h" header.
a390a846	2017-07-01T13:06:00	cmake: move defines into "features.h" header In a future commit, we will split out the build instructions for our library directory and move them into a subdirectory. One of the benefits is fixing scoping issues, where e.g. defines do not leak to build targets where they do not belong to. But unfortunately, this does also pose the problem of how to propagate some defines which are required by both the library and the test suite. One way would be to create another variable keeping track of all added defines and declare it inside of the parent scope. While this is the most obvious and simplest way of going ahead, it is kind of unfortunate. The main reason to not use this is that these defines become implicit dependencies between the build targets. By simply observing a define inside of the CMakeLists.txt file, one cannot reason whether this define is only required by the current target or whether it is required by different targets, as well. Another approach would be to use an internal header file keeping track of all defines shared between targets. While configuring the library, we will set various variables and let CMake configure the file, adding or removing defines based on what has been configured. Like this, one can easily keep track of the current environment by simply inspecting the header file. Furthermore, these dependencies are becoming clear inside the CMakeLists.txt, as instead of simply adding a define, we now call e.g. `SET(GIT_THREADSAFE 1)`. Having this header file though requires us to make sure it is always included before any "#ifdef"-preprocessor checks are executed. As we have already refactored code to always include the "common.h" header file before any statement inside of a file, this becomes easy: just make sure "common.h" includes the new "features.h" header file first.
35087f0e	2017-06-28T15:42:54	cmake: create separate CMakeLists.txt for tests Our CMakeLists.txt is very unwieldy in its current size, spanning more than 700 lines of code. Furthermore, it has several issues regarding scoping, where for example some defines, includes, etc. from our test suite are also applied to our normal library code. To fix this, we can separate out build instructions for our tests and move them into their own CMakeLists.txt in the "tests" directory. This reduced complexity of the root CMakeLists.txt file and fixes the issues regarding leaking build context from tests into the library.
3267115f	2017-06-28T15:41:15	cmake: create own precompiled headers for tests As soon as we split up our CMakeBuild.txt build instructions, we will be unable to simply link against the git2 library's precompiled header from other targets. To avoid this future breakage, create a new precompiled header for our test suite. Next to being compatible with the split, this enables us to also include additional files like the clar headers, which may help speeding up compilation of the test suite.
caab8270	2017-06-23T19:07:01	cmake: create object library target Currently, we're compiling our library code twice, once as part of the libgit2 library and once for the libgit2_clar executable. Since CMake 2.8.8, there exists a new library type OBJECT, which represents an intermediate target which can then subsequently be used when linking several targets against the same set of objects. Use an OBJECT library to create an internal library for linking. This new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed the way how generator expressions are evaluated when accessing properties, we need to enable CMake policy 0051 to keep `IDE_SPLIT_SOURCES` functioning.
f33911e5	2017-06-23T18:32:48	cmake: remove unused variable "CLAR_RESOURCES" Once upon a time, the `CLAR_RESOURCES` variable was intended to set the `CLAR_RESOURCES` define. But actually, the define uses a wrong variable name by accident, hinting that its value cannot actually be used at all, as it is empty. Searching through the code base confirms the guess that the define is not used at all. Remove both the variable and definition.
096a49c0	2017-07-03T08:45:57	cmake: try to detect threads library While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`, it is actually undefined due to us never including the "FindThreads" module in the CMakeLists.txt. It is rather curious as to why this has never triggered any error up to now, but it does in fact result in linking errors on some Unix platforms as soon as we split up our build instructions into multiple files. Fix the issue now to avoid future breakage by including the "FindThreads" module.
8a43161b	2017-07-05T12:18:17	cmake: always include our own headers first With c26ce7840 (Merge branch 'AndreyG/cmake/modernization', 2017-06-28), we have recently introduced a regression in the way we are searching for headers. We have made sure to always include our own headers first, but due to the changes in c26ce7840 this is no longer guaranteed. In fact, this already leads the compiler into picking "config.h" from the "deps/regex" dependency, if it is used. Fix the issue by declaring our internal include directories up front, before any of the other search directories is added.
e5c9723d	2017-06-30T18:12:02	cmake: move library build instructions into subdirectory To fix leaking build instructions into different targets and to make the build instructions easier to handle, create a new CMakeLists.txt file containing build instructions for the libgit2 target. By now, the split is rather easy to achieve. Due to the preparatory steps, we can now simply move over all related build instructions, only needing to remove the "src/" prefix from some files.
72f27cb6	2017-06-30T17:02:00	cmake: fix up source and binary directory paths There are quite some uses of the variables "${CMAKE_CURRENT_SOURCE_DIR}" and "${CMAKE_CURRENT_BINARY_DIR}" where they are not appropriate. Convert these sites to instead use the variables "${CMAKE_SOURCE_DIR}" and "${CMAKE_BINARY_DIR}", which instead point to the project's root directory. This will ease splitting up the library build instructions into its own subdirectory.
1560b580	2017-08-15T10:35:47	Merge pull request #4288 from pks-t/pks/include-fixups Include fixups
6be167f1	2017-08-14T22:04:29	Merge pull request #4330 from alpha0010/patch-1 Docs: Fix inline comments for git_diff_hunk
577aeef7	2017-08-14T22:02:26	Merge pull request #4328 from libgit2/peff/hashcmp-is-memcmp oid: use memcmp in git_oid__hashcmp
f908b184	2017-08-14T22:00:51	Merge pull request #4327 from libgit2/peff/drop-sha1-entry-pos sha1_lookup: drop sha1_entry_pos function
e536fa33	2017-08-14T21:59:11	Merge pull request #4326 from libgit2/peff/binary-search-do-while sha1_position: convert do-while to while
2a3cfc23	2017-08-11T17:15:51	Docs: Fix inline comments for git_diff_hunk
c9b1e646	2017-08-09T16:54:07	oid: use memcmp in git_oid__hashcmp The open-coded version was inherited from git.git. But it turns out it was based on an older version of glibc, whose memcmp was not very optimized. Modern glibc does much better, and some compilers (like gcc 7) can even inline the memcmp into a series of multi-byte xors. Upstream is switching to using memcmp in git/git@0b006014c87f400bd9a86267ed30fd3e7b383884.
9842b327	2017-08-09T16:47:14	sha1_lookup: drop sha1_entry_pos function This was pulled over from git.git, and is an experiment in making binary-searching lists of sha1s faster. It was never compiled by default (nor was it used upstream by default without a special environment variable). Unfortunately, it is actually slower in practice, and upstream is planning to drop it in git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has some timing results). It's worth doing the same here for simplicity.
09930192	2017-08-09T16:34:02	sha1_position: convert do-while to while If we enter the sha1_position() function with "lo == hi", we have no elements. But the do-while loop means that we'll enter the loop body once anyway, picking "mi" at that same value and comparing nonsense to our desired key. This is unlikely to match in practice, but we still shouldn't be looking at the memory in the first place. This bug is inherited from git.git; it was fixed there in e01580cfe01526ec2c4eb4899f776a82ade7e0e1.
a9d6b9d5	2017-07-31T01:20:21	Merge pull request #4304 from pks-t/pks/patch-buffers patch_generate: represent buffers as void pointers
dca8c44f	2017-07-31T01:17:24	Merge pull request #4323 from libgit2/ethomson/remove_sys_remote_h Remove unused 'sys/remote.h' header
fb585d01	2017-07-31T00:58:58	Merge branch '4233'
868ce84f	2017-07-31T00:58:35	changelog: update to reflect `detached` api name
37841317	2017-07-31T00:38:28	Remove unused 'sys/remote.h' header
d55431eb	2017-07-28T11:19:24	Merge pull request #4320 from pks-t/pks/rebase-submodule-asserts tests: rebase::submodule: verify initialization method calls
c0558c62	2017-07-28T09:01:41	tests: rebase::submodule: verify initialization method calls Some return codes for functions which may fail are not being checked in `test_rebase_submodule__initialize`. This may lead us to not notice errors when initializing the environment and would possibly result in either memory corruption or segfaults as soon as any of the initialization steps fails. Fix this by wrapping these function calls into `cl_git_pass`.
4f4bc573	2017-07-27T23:05:53	Merge pull request #4275 from tiennou/fix-rebase-submodule-test tests: rewrite rebase-submodule .gitmodule file
ed00ac06	2017-07-26T23:24:28	Merge pull request #4314 from pks-t/pks/timsort tsort: remove idempotent conditional assignment
8f9d2bbf	2017-07-26T23:23:37	Merge pull request #4317 from libgit2/ethomson/libcurl_build Build with patched libcurl
20d30000	2017-07-26T11:03:27	Merge pull request #4311 from libgit2/ethomson/win32_remediate win32: provide fast-path for retrying filesystem operations
bc35fd4b	2017-07-18T14:44:29	win32: provide fast-path for retrying filesystem operations When using the `do_with_retries` macro for retrying filesystem operations in the posix emulation layer, allow the remediation function to return `GIT_RETRY`, meaning that the error was believed to be remediated, and the operation should be retried immediately, without a sleep. This is a slightly more general solution to the problem fixed in #4312.
192a87e1	2017-07-18T14:55:56	Updated changelog
1bcdaba2	2017-07-18T14:47:28	fixed win32 p_unlink retry sleep issue Fixed an issue where the retry logic on p_unlink sleeps before it tries setting a file to write mode causing unnecessary slowdown.
35cb7b84	2017-07-20T21:00:15	tests: fix the rebase-submodule test
c582fa4e	2017-07-24T17:53:32	travis: only install custom libcurl on trusty
697583ea	2017-07-24T16:48:04	travis: only kill our own sshd
4da38193	2017-07-24T13:10:43	travis: use trusty
f031e20b	2017-07-23T03:41:52	travis: build with patched libcurl Ubuntu trusty has a bug in curl when using NTLM credentials in a proxy, dereferencing a null pointer and causing segmentation faults. Use a custom-patched version of libcurl that avoids this issue.
fdbb40fd	2017-07-21T11:26:13	tsort: remove idempotent conditional assignment The conditional `run < minrun` can never be true directly after assigning `run = minrun`. Remove it to avoid confusion.
45994fdc	2017-06-21T14:57:30	Remove invalid submodule Fixes #4274
e0568621	2017-07-19T13:55:55	Merge pull request #4250 from pks-t/pks/config-file-iteration Configuration file fixes with includes
a94a5402	2017-07-19T13:28:32	Merge pull request #4272 from pks-t/pks/patch-id Patch ID calculation
1b329089	2017-05-31T22:27:19	config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.
28c2cc3d	2017-05-31T16:41:44	config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.
83bcd3a1	2017-05-31T22:45:25	config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.
56a7a264	2017-05-31T14:50:40	config_file: remove unused backend field from parse data The backend passed to `config_read` is never actually used anymore, so we can remove it from the function and the `parse_data` structure.
3a7f7a6e	2017-05-31T14:43:46	config_file: pass reader directly to callbacks Previously, the callbacks passed to `config_parse` got the reader via a pointer to a pointer. This allowed the callbacks to update the callers `reader` variable when the array holding it has been reallocated. As the array is no longer present, we can simply the code by making the reader a simple pointer.
73df75d8	2017-05-31T14:34:48	config_file: refactor include handling Current code for configuration files uses the `reader` structure to parse configuration files and store additional metadata like the file's path and checksum. These structures are stored within an array in the backend itself, which causes multiple problems. First, it does not make sense to keep around the file's contents with the backend itself. While this data is usually free'd before being added to the backend, this brings along somewhat intricate lifecycle problems. A better solution would be to store only the file paths as well as the checksum of the currently parsed content only. The second problem is that the `reader` structures are stored inside an array. When re-parsing configuration files due to changed contents, we may cause this array to be reallocated, requiring us to update pointers hold by callers. Furthermore, we do not keep track of includes which are already associated to a reader inside of this array. This causes us to add readers multiple times to the backend, e.g. in the scenario of refreshing configurations. This commit fixes these shortcomings. We introduce a split between the parsing data and the configuration file's metadata. The `reader` will now only hold the file's contents and the parser state and the new `config_file` structure holds the file's path and checksum. Furthermore, the new structure is a recursive structure in that it will also hold references to the files it directly includes. The diskfile is changed to only store the top-level configuration file. These changes allow us further refactorings and greatly simplify understanding the code.
6f7aab0c	2017-06-06T09:45:11	tests: config::include: use init and cleanup functions
8149f850	2017-07-14T08:30:18	Merge pull request #4306 from libgit2/cmn/tag-bad-signature signature: don't leave a dangling pointer to the strings on parse failure
d1dbb3ae	2017-07-12T07:40:16	signature: don't leave a dangling pointer to the strings on parse failure If the signature is invalid but we detect that after allocating the strings, we free them. We however leave that pointer dangling in the structure the caller gave us, which can lead to double-free. Set these pointers to `NULL` after freeing their memory to avoid this.
9093ced6	2017-07-10T11:42:26	patch_generate: represent buffers as void pointers Pointers to general data should usually be used as a void pointer such that it is possible to hand in variables of a different pointer type without the need to cast. This is the same when creating patches from buffers, where the buffers may contain arbitrary data. Instead of requiring the caller to care whether his buffer is e.g. `char ` or `unsigned char `, we should instead just accept a `void *`. This is also consistent in how we tread other types like for example `git_blob`, which also just has a void pointer as its raw contents.
c4c95bf4	2017-07-10T08:50:11	Merge pull request #4287 from AndreyG/reset/interface-cosmetics git_reset_*: pass parameters as const pointers
0e165686	2017-07-07T10:03:34	Merge pull request #4291 from pks-t/pks/regex-header-confusion tests: config: fix missing declaration causing error
1f7af277	2017-07-05T11:52:47	tests: config: fix missing declaration causing error On systems where we pull in our distributed version of the regex library, all tests in config::readonly fail. This error is actually quite interesting: the test suite is unable to find the declaration of `git_path_exists` and assumes it has a signature of `int git_path_exists(const char *)`. But actually, it has a `bool` return value. Due to this confusion, some wrong conversion is done by the compiler and the `cl_assert(!git_path_exists("file"))` checks erroneously fail, even when the function does in fact return the correct value. The error is actually introduced by 56893bb9a (cmake: consistently use TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately introduced by myself. Due to the delayed addition of include directories, we will now find the "config.h" header inside of the "deps/regex" directory instead of inside the "src/" directory, where it should be. As such, we are missing definitions for the `git_config_file__ondisk` and `git_path_exists` symbols. The correct fix here would be to fix the order in which include search directories are added. But due to the current restructuring of CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a bit. Instead, we paper over the issue by explicitly including "path.h" to fix its prototype. This ignores the issue that `git_config_file__ondisk` is undeclared, as its signature is correctly identified by the compiler.
0c7f49dd	2017-06-30T13:39:01	Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
2480d0eb	2017-06-30T13:34:05	Add missing license headers Some implementation files were missing the license headers. This commit adds them.
0fb4b351	2017-06-30T13:27:26	Fix missing include for header files Some of our header files are not included at all by any of their implementing counter-parts. Including them inside of these files leads to some compile errors mostly due to unknown types because of missing includes. But there's also one case where a declared function does not match the implementation's prototype. Fix all these errors by fixing up the prototype and adding missing includes. This is preparatory work for fixing up missing includes in the implementation files.
9b0482e4	2017-06-30T19:24:15	zlib: include "git2/types.h" instead of "common.h" The zlib dependency includes "common.h" inside of the "zconf.h" header to make available some type declarations like e.g. git_off_t. Including the "common.h" header does pull in quite a lot of other headers though, which are not required at all. Instead, we can just include our public "git2/types.h" header, which is much more limited in its scope but still provides everything required for "zconf.h". This fix eases the transition later on to use a separate "features.h" header instead of defines. As we have to generate the "features.h" header, we put it in the build directory and add an include directory. As we are splitting out building of dependencies into subdirectories, this would mean that the zlib dependency needs to be aware of the parent project's build directory, which is unfortunate. By including "git2/types.h", we avoid this problem.
459fb8fe	2017-06-30T15:35:46	win32: fix circular include deps with w32_crtdbg The current order of declarations and includes between "common.h" and "w32_crtdbg_stacktrace.h" is rather complicated. Both header files make use of things defined in the other one and are thus circularly dependent on each other. This makes it currently impossible to compile the "w32_crtdbg_stacktrace.c" file when including "common.h" inside of "w32_crtdbg_stacktrace.h". We can disentangle the mess by moving declaration of the inline crtdbg functions into the "w32_crtdbg_stacktrace.h" file and adding additional includes inside of it, such that all required functions are available to it. This allows us to break the dependency cycle.
d4e03be6	2017-06-30T11:21:18	git_reset_*: pass parameters as const pointers
c26ce784	2017-06-28T12:26:04	Merge branch 'AndreyG/cmake/modernization'

212da30d

2017-09-16T19:49:04

Merge pull request #4348 from pks-t/pks/win32-hash-memleak diff: cleanup hash ctx in `git_diff_patchid`

d378e384

2017-09-15T17:53:01

Merge pull request #4347 from pks-t/pks/appveyor-vs2015 Fix AppVeyor build failures due to CRTDBG linking issue

03a95bc5

2017-09-15T11:32:46

appveyor: add jobs to also build on Visual Studio 2015 In order to cover a wider range of build environments, add two more jobs which build and test libgit2 on Visual Studio 14 2015.

e1076dbf

2017-09-15T10:01:36

appveyor: explicitly specify build images AppVeyor currently does provide three standard build worker images with VS2013, VS2015 and VS2017. Right now, we are using the implicitly, which is the VS2015 one. We want to be more explicit about this, so that we can easily switch build images based on the job. So starting from this commit, we explicitly set the `APPVEYOR_BUILD_WORKER_IMAGE` variable per job, which enables us to choose different images. To be able to test a wider range of build configurations, this commit also switches the jobs for VC2010 over to use the older, VS2013 based images. As the next commit will introduce two new jobs for building with VS2015, we have then covered both build environments. Also, let us be a bit more explicit regarding the CMake generator. Instead of only saying "Visual Studio 10", use the more descriptive value "Visual Studio 10 2010" to at least avoid some confusion surrounding the versioning scheme of Visual Studio.

54214d61

2017-09-15T10:28:32

cmake: fix linker error with dbghelper library When the MSVC_CRTDBG option is set by the developer, we will link in the dbghelper library to enable memory lead detection in MSVC projects. We are doing so by adding it to the variable `CMAKE_C_STANDARD_LIBRARIES`, so that it is linked for every library and executable built by CMake. But this causes our builds to fail with a linker error: ``` LINK: fatal error LNK1104: cannot open file 'advapi32.lib;Dbghelp.lib' ``` The issue here is that we are treating the variable as if it were an array of libraries by setting it via the following command: ``` SET(CMAKE_C_STANDARD_LIBRARIES "${CMAKE_C_STANDARD_LIBRARIES}" "Dbghelp.lib") ``` The generated build commands will then simply stringify the variable, concatenating all the contained libraries with a ";". This causes the observed linking failure. To fix the issue, we should just treat the variabable as a simple string. So instead of adding multiple members, we just add the "Dbghelp.lib" library to the existing string, separated by a space character.

046b081a

2017-09-15T10:46:26

diff: cleanup hash ctx in `git_diff_patchid` After initializing the hash context in `git_diff_patchid`, we never proceed to call `git_hash_ctx_cleanup` on it. While this doesn't really matter on most hash implementations, this causes a memory leak on Win32 due to CNG system requiring a `malloc` call. Fix the memory leak by always calling `git_hash_ctx_cleanup` before exiting.

e098b5f5

2017-09-12T20:21:27

Merge pull request #4344 from slavikus/fix-dirty-buffer-in-git-push-update-tips Clear the remote_ref_name buffer in git_push_update_tips()

71a8204d

2017-09-12T20:20:48

Merge pull request #4346 from pks-t/pks/wo-features-header features.h: allow building without CMake-generated feature header

26f531d3

2017-09-12T13:35:18

features.h: allow building without CMake-generated feature header In commit a390a8464 (cmake: move defines into "features.h" header, 2017-07-01), we have introduced a new "features.h" header. This file is being generated by the CMake build system based on how the libgit2 build has been configured, replacing the preexisting method of simply setting the defines inside of the CMake build system. This was done to help splitting up the build instructions into multiple separate subdirectories. An overlooked shortcoming of this approach is that some projects making use of libgit2 build the library with custom build systems, without making use of CMake. For those users, the introduction of the "features.h" file makes their life harder as they would have to also generate this file. Fix this issue by guarding all inclusions of the generated header file by the `LIBGIT2_NO_FEATURES_H` define. Like this, other build systems can skip the feature header and simply define all used features by specifying `-D` flags for the compiler again.

b34fc3fd

2017-09-11T21:34:41

Clear the remote_ref_name buffer in git_push_update_tips() If fetch_spec was a non-pattern, and it is not the first iteration of push_status vector, then git_refspec_transform would result in the new value appended via git_buf_puts to the previous iteration value. Forcibly clearing the buffer on each iteration to prevent this behavior.

5b947b62

2017-09-10T14:47:04

Merge pull request #4342 from mothacehe/master README: Mention Guile-Git bindings.

b4e0d293

2017-09-09T09:54:58

README: Mention Guile-Git bindings.

3c216453

2017-08-25T21:06:46

Merge pull request #4296 from pks-t/pks/pattern-based-gitignore Fix negative ignore rules with patterns

4b000fc0

2017-08-25T21:05:20

Merge pull request #4305 from pks-t/pks/submodule-with-bare-repo Submodules with bare repo

bcb7e92d

2017-08-25T21:04:04

Merge pull request #4279 from pks-t/pks/error-builds -Werror builds for Travis

477b3e04

2017-07-10T12:25:43

submodule: refuse lookup in bare repositories While it is technically possible to look up submodules inside of a bare repository by reading the submodule configuration of a specific commit, we do not offer this functionality right now. As such, calling both `git_submodule_lookup` and `git_submodule_foreach` should error out early when these functions encounter a bare repository. While `git_submodule_lookup` already does return an error due to not being able to parse the configuration, `git_submodule_foreach` simply returns success and never invokes the callback function. Fix the issue by having both functions check whether the repository is bare and returning an error in that case.

a889c05f

2017-07-10T11:55:33

tests: submodule: add explicit cleanup function in lookup tests

64d1e0b3

2017-07-10T11:52:08

tests: submodule: fix declaration of test The testcase "submodule::lookup::cached" was declared with a single underscore separating the test suide and test name, only. As the clar parser only catches tests with two underscores, it was never executed. Add in the second underscore to actually have it detected and executed.

2d9ff8f5

2017-07-10T09:36:19

ignore: honor case insensitivity for negative ignores When computing negative ignores, we throw away any rule which does not undo a previous rule to optimize. But on case insensitive file systems, we need to keep in mind that a negative ignore can also undo a previous rule with different case, which we did not yet honor while determining whether a rule undoes a previous one. So in the following example, we fail to unignore the "/Case" directory: /case !/Case Make both paths checking whether a plain- or wildcard-based rule undo a previous rule aware of case-insensitivity. This fixes the described issue.

38b44c3b

2017-07-07T17:10:57

tests: status: additional test for negative ignores with pattern This test is by Carlos Martín Nieto.

b8922fc8

2017-07-07T13:27:27

ignore: keep negative rules containing wildcards Ignore rules allow for reverting a previously ignored rule by prefixing it with an exclamation mark. As such, a negative rule can only override previously ignored files. While computing all ignore patterns, we try to use this fact to optimize away some negative rules which do not override any previous patterns, as they won't change the outcome anyway. In some cases, though, this optimization causes us to get the actual ignores wrong for some files. This may happen whenever the pattern contains a wildcard, as we are unable to reason about whether a pattern overrides a previous pattern in a sane way. This happens for example in the case where a gitignore file contains "*.c" and "!src/*.c", where we wouldn't un-ignore files inside of the "src/" subdirectory. In this case, the first solution coming to mind may be to just strip the "src/" prefix and simply compare the basenames. While that would work here, it would stop working as soon as the basename pattern itself is different, like for example with "*x.c" and "!src/*.c. As such, we settle for the easier fix of just not optimizing away rules that contain a wildcard.

4467543e

2017-07-07T12:27:43

ignore: return early to avoid useless indentation

9bd83622

2017-07-07T12:27:18

ignore: fix indentation of comment block

414a3384

2017-08-25T17:36:59

travis: error on compiler warnings One of our goals is to have our code free of any warnings. Due to the recent switch to Ubuntu 14.04 on Travis, the last warning regarding some preprocessor-magic in the curl-headers has been fixed and as such, the goal of zero warnings is now reached for Travis CI. In order to avoid introducing new warnings via pull requests, we can now enable building with `-Werror` and turn compiler warnings into errors instead, causing the CI jobs to fail. This build does so by passing the newly introdcued `-DENABLE_WERROR` flag to CMake for all Travis jobs.

175ab8e7

2017-08-25T17:36:24

cmake: add switch to build with -Werror Add a simple switch to enable building with "-Werror=<warning>" instead of "-W<warning". Due to the encapsulated `ENABLE_WARNINGS` macro, this is as simple as adding a new variable "ENABLE_WERROR`, which can be passed on the command line via `-DENABLE_WERROR=ON`. The variable defaults to NO to not bother developers in their day to day work.

4a46a8c1

2017-08-25T17:32:54

cmake: encapsulate enabling/disabling compiler warnings There are multiple sites where we enable or disable compiler warning via "-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism later on to conditionally switch these over to "-Werror=<warning>", we encapsulate the logic into its their own macros `ENABLE_WARNINGS` and `DISABLE_WARNINGS`. Note that we in fact have to use a macro here. Using a function would not modify the CFLAGS inside of the callers scope, but in the function's scope only.

0a93ded1

2017-08-24T21:23:58

Merge pull request #4282 from pks-t/pks/remove-unused-clar-fixtures Split up CMakeLists.txt build instructions

a3a35473

2017-08-17T08:38:47

cmake: fix output location of import libraries and DLLs As observed by Edward Thomson, the libgit2 DLL built by Windows will not end up in the top-level build directory but instead inside of the 'src/' subdirectory. While confusing at first because we are actually setting the LIBRARY_OUTPUT_DIRECTORY to the project's binary directory, the manual page of LIBRARY_OUTPUT_DIRECTORY clears this up: There are three kinds of target files that may be built: archive, library, and runtime. Executables are always treated as runtime targets. Static libraries are always treated as archive targets. Module libraries are always treated as library targets. For non-DLL platforms shared libraries are treated as library targets. For DLL platforms the DLL part of a shared library is treated as a runtime target and the corresponding import library is treated as an archive target. All Windows-based systems including Cygwin are DLL platforms. So in fact, DLLs and import libraries are not treated as libraries at all by CMake but instead as runtime and archive targets. To fix the issue, we can thus simply set the variables RUNTIME_OUTPUT_DIRECTORY and ARCHIVE_OUTPUT_DIRECTORY to the project's root binary directory.

1f43a43d

2017-06-28T13:28:33

cmake: move zlib build instructions into subdirectory Extract code required to build the zlib library into its own CMakeLists.txt, which is included as required.

b7514554

2017-06-28T13:25:09

cmake: move http-parser build instructions into subdirectory Extract code required to build the http-parser library into its own CMakeLists.txt, which is included as required.

9e449e52

2017-06-28T13:23:45

cmake: move regex build instructions into subdirectory Extract code required to build the regex library into its own CMakeLists.txt, which is included as required.

43248500

2017-06-28T13:21:09

cmake: move winhttp build instructions into subdirectory Extract code required to build the winhttp library into its own CMakeLists.txt, which is included as required.

bed7ca3a

2017-06-30T16:57:16

cmake: define WIN_RC with other platform sources This makes splitting up the library build instructions later on more obvious and easier to achieve.

8ee90c39

2017-06-28T13:16:38

cmake: find dependencies after setting build flags This makes splitting up the library build instructions later on more obvious and easier to achieve.

c3635130

2017-06-28T13:14:23

cmake: move definition of Win32 flags together This makes splitting up the library build instructions later on more obvious and easier to achieve.

32a2e500

2017-07-01T13:41:36

cmake: inline TARGET_OS_LIBRARIES function Previous to keeping track of libraries and linking directories via variables, we had two call sites of the `TARGET_OS_LIBRARIES` function to avoid duplicating knowledge on required operating system library dependencies. But as the libgit2_clar target now re-uses defined variables to link against these libraries, we can simply inline the function.

8e31cc25

2017-06-28T12:51:14

cmake: keep track of libraries and includes via lists Later on, we will move detection of required libraries, library directories as well as include directories into a separate CMakeLists.txt file inside of the source directory. Obviously, we want to avoid duplication here regarding these parameters. To prepare for the split, put the parameters into three variables LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the required libraries, linking directory as well as include directories. These variables can later be exported into the parent scope from inside of the source build instructions, making them readily available for the other subdirectories.

dd332e2a

2017-06-23T20:42:41

cmake: use absolute path to deps When refering to files and directories inside of the top-level "deps/" directory, we're being inconsistent in using relative or absolute paths. To enable splitting out parts of the top-level CMakeLists.txt into an own file in the "src/" directory, consistently switch over to use absolute paths to avoid errors when converting.

8341d6cf

2017-07-04T10:57:28

cmake: move regcomp and futimens checks to "features.h" In our CMakeLists.txt, we have to check multiple functions in order to determine if we have to use our own or whether we can use the platform-provided one. For two of these functions, namely `regcomp_l()` and `futimens`, the defined macro is actually used inside of the header file "src/unix/posix.h". As such, these macros are not only required by the library, but also by our test suite, which is makes use of internal headers. To prepare for the CMakeLists.txt split, move these two defines inside of the "features.h" header.

a390a846

2017-07-01T13:06:00

cmake: move defines into "features.h" header In a future commit, we will split out the build instructions for our library directory and move them into a subdirectory. One of the benefits is fixing scoping issues, where e.g. defines do not leak to build targets where they do not belong to. But unfortunately, this does also pose the problem of how to propagate some defines which are required by both the library and the test suite. One way would be to create another variable keeping track of all added defines and declare it inside of the parent scope. While this is the most obvious and simplest way of going ahead, it is kind of unfortunate. The main reason to not use this is that these defines become implicit dependencies between the build targets. By simply observing a define inside of the CMakeLists.txt file, one cannot reason whether this define is only required by the current target or whether it is required by different targets, as well. Another approach would be to use an internal header file keeping track of all defines shared between targets. While configuring the library, we will set various variables and let CMake configure the file, adding or removing defines based on what has been configured. Like this, one can easily keep track of the current environment by simply inspecting the header file. Furthermore, these dependencies are becoming clear inside the CMakeLists.txt, as instead of simply adding a define, we now call e.g. `SET(GIT_THREADSAFE 1)`. Having this header file though requires us to make sure it is always included before any "#ifdef"-preprocessor checks are executed. As we have already refactored code to always include the "common.h" header file before any statement inside of a file, this becomes easy: just make sure "common.h" includes the new "features.h" header file first.

35087f0e

2017-06-28T15:42:54

cmake: create separate CMakeLists.txt for tests Our CMakeLists.txt is very unwieldy in its current size, spanning more than 700 lines of code. Furthermore, it has several issues regarding scoping, where for example some defines, includes, etc. from our test suite are also applied to our normal library code. To fix this, we can separate out build instructions for our tests and move them into their own CMakeLists.txt in the "tests" directory. This reduced complexity of the root CMakeLists.txt file and fixes the issues regarding leaking build context from tests into the library.

3267115f

2017-06-28T15:41:15

cmake: create own precompiled headers for tests As soon as we split up our CMakeBuild.txt build instructions, we will be unable to simply link against the git2 library's precompiled header from other targets. To avoid this future breakage, create a new precompiled header for our test suite. Next to being compatible with the split, this enables us to also include additional files like the clar headers, which may help speeding up compilation of the test suite.

caab8270

2017-06-23T19:07:01

cmake: create object library target Currently, we're compiling our library code twice, once as part of the libgit2 library and once for the libgit2_clar executable. Since CMake 2.8.8, there exists a new library type OBJECT, which represents an intermediate target which can then subsequently be used when linking several targets against the same set of objects. Use an OBJECT library to create an internal library for linking. This new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed the way how generator expressions are evaluated when accessing properties, we need to enable CMake policy 0051 to keep `IDE_SPLIT_SOURCES` functioning.

f33911e5

2017-06-23T18:32:48

cmake: remove unused variable "CLAR_RESOURCES" Once upon a time, the `CLAR_RESOURCES` variable was intended to set the `CLAR_RESOURCES` define. But actually, the define uses a wrong variable name by accident, hinting that its value cannot actually be used at all, as it is empty. Searching through the code base confirms the guess that the define is not used at all. Remove both the variable and definition.

096a49c0

2017-07-03T08:45:57

cmake: try to detect threads library While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`, it is actually undefined due to us never including the "FindThreads" module in the CMakeLists.txt. It is rather curious as to why this has never triggered any error up to now, but it does in fact result in linking errors on some Unix platforms as soon as we split up our build instructions into multiple files. Fix the issue now to avoid future breakage by including the "FindThreads" module.

8a43161b

2017-07-05T12:18:17

cmake: always include our own headers first With c26ce7840 (Merge branch 'AndreyG/cmake/modernization', 2017-06-28), we have recently introduced a regression in the way we are searching for headers. We have made sure to always include our own headers first, but due to the changes in c26ce7840 this is no longer guaranteed. In fact, this already leads the compiler into picking "config.h" from the "deps/regex" dependency, if it is used. Fix the issue by declaring our internal include directories up front, before any of the other search directories is added.

e5c9723d

2017-06-30T18:12:02

cmake: move library build instructions into subdirectory To fix leaking build instructions into different targets and to make the build instructions easier to handle, create a new CMakeLists.txt file containing build instructions for the libgit2 target. By now, the split is rather easy to achieve. Due to the preparatory steps, we can now simply move over all related build instructions, only needing to remove the "src/" prefix from some files.

72f27cb6

2017-06-30T17:02:00

cmake: fix up source and binary directory paths There are quite some uses of the variables "${CMAKE_CURRENT_SOURCE_DIR}" and "${CMAKE_CURRENT_BINARY_DIR}" where they are not appropriate. Convert these sites to instead use the variables "${CMAKE_SOURCE_DIR}" and "${CMAKE_BINARY_DIR}", which instead point to the project's root directory. This will ease splitting up the library build instructions into its own subdirectory.

1560b580

2017-08-15T10:35:47

Merge pull request #4288 from pks-t/pks/include-fixups Include fixups

6be167f1

2017-08-14T22:04:29

Merge pull request #4330 from alpha0010/patch-1 Docs: Fix inline comments for git_diff_hunk

577aeef7

2017-08-14T22:02:26

Merge pull request #4328 from libgit2/peff/hashcmp-is-memcmp oid: use memcmp in git_oid__hashcmp

f908b184

2017-08-14T22:00:51

Merge pull request #4327 from libgit2/peff/drop-sha1-entry-pos sha1_lookup: drop sha1_entry_pos function

e536fa33

2017-08-14T21:59:11

Merge pull request #4326 from libgit2/peff/binary-search-do-while sha1_position: convert do-while to while

2a3cfc23

2017-08-11T17:15:51

Docs: Fix inline comments for git_diff_hunk

c9b1e646

2017-08-09T16:54:07

oid: use memcmp in git_oid__hashcmp The open-coded version was inherited from git.git. But it turns out it was based on an older version of glibc, whose memcmp was not very optimized. Modern glibc does much better, and some compilers (like gcc 7) can even inline the memcmp into a series of multi-byte xors. Upstream is switching to using memcmp in git/git@0b006014c87f400bd9a86267ed30fd3e7b383884.

9842b327

2017-08-09T16:47:14

sha1_lookup: drop sha1_entry_pos function This was pulled over from git.git, and is an experiment in making binary-searching lists of sha1s faster. It was never compiled by default (nor was it used upstream by default without a special environment variable). Unfortunately, it is actually slower in practice, and upstream is planning to drop it in git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has some timing results). It's worth doing the same here for simplicity.

09930192

2017-08-09T16:34:02

sha1_position: convert do-while to while If we enter the sha1_position() function with "lo == hi", we have no elements. But the do-while loop means that we'll enter the loop body once anyway, picking "mi" at that same value and comparing nonsense to our desired key. This is unlikely to match in practice, but we still shouldn't be looking at the memory in the first place. This bug is inherited from git.git; it was fixed there in e01580cfe01526ec2c4eb4899f776a82ade7e0e1.

a9d6b9d5

2017-07-31T01:20:21

Merge pull request #4304 from pks-t/pks/patch-buffers patch_generate: represent buffers as void pointers

dca8c44f

2017-07-31T01:17:24

Merge pull request #4323 from libgit2/ethomson/remove_sys_remote_h Remove unused 'sys/remote.h' header

fb585d01

2017-07-31T00:58:58

Merge branch '4233'

868ce84f

2017-07-31T00:58:35

changelog: update to reflect `detached` api name

37841317

2017-07-31T00:38:28

Remove unused 'sys/remote.h' header

d55431eb

2017-07-28T11:19:24

Merge pull request #4320 from pks-t/pks/rebase-submodule-asserts tests: rebase::submodule: verify initialization method calls

c0558c62

2017-07-28T09:01:41

tests: rebase::submodule: verify initialization method calls Some return codes for functions which may fail are not being checked in `test_rebase_submodule__initialize`. This may lead us to not notice errors when initializing the environment and would possibly result in either memory corruption or segfaults as soon as any of the initialization steps fails. Fix this by wrapping these function calls into `cl_git_pass`.

4f4bc573

2017-07-27T23:05:53

Merge pull request #4275 from tiennou/fix-rebase-submodule-test tests: rewrite rebase-submodule .gitmodule file

ed00ac06

2017-07-26T23:24:28

Merge pull request #4314 from pks-t/pks/timsort tsort: remove idempotent conditional assignment

8f9d2bbf

2017-07-26T23:23:37

Merge pull request #4317 from libgit2/ethomson/libcurl_build Build with patched libcurl

20d30000

2017-07-26T11:03:27

Merge pull request #4311 from libgit2/ethomson/win32_remediate win32: provide fast-path for retrying filesystem operations

bc35fd4b

2017-07-18T14:44:29

win32: provide fast-path for retrying filesystem operations When using the `do_with_retries` macro for retrying filesystem operations in the posix emulation layer, allow the remediation function to return `GIT_RETRY`, meaning that the error was believed to be remediated, and the operation should be retried immediately, without a sleep. This is a slightly more general solution to the problem fixed in #4312.

192a87e1

2017-07-18T14:55:56

Updated changelog

1bcdaba2

2017-07-18T14:47:28

fixed win32 p_unlink retry sleep issue Fixed an issue where the retry logic on p_unlink sleeps before it tries setting a file to write mode causing unnecessary slowdown.

35cb7b84

2017-07-20T21:00:15

tests: fix the rebase-submodule test

c582fa4e

2017-07-24T17:53:32

travis: only install custom libcurl on trusty

697583ea

2017-07-24T16:48:04

travis: only kill our own sshd

4da38193

2017-07-24T13:10:43

travis: use trusty

f031e20b

2017-07-23T03:41:52

travis: build with patched libcurl Ubuntu trusty has a bug in curl when using NTLM credentials in a proxy, dereferencing a null pointer and causing segmentation faults. Use a custom-patched version of libcurl that avoids this issue.

fdbb40fd

2017-07-21T11:26:13

tsort: remove idempotent conditional assignment The conditional `run < minrun` can never be true directly after assigning `run = minrun`. Remove it to avoid confusion.

45994fdc

2017-06-21T14:57:30

Remove invalid submodule Fixes #4274

e0568621

2017-07-19T13:55:55

Merge pull request #4250 from pks-t/pks/config-file-iteration Configuration file fixes with includes

a94a5402

2017-07-19T13:28:32

Merge pull request #4272 from pks-t/pks/patch-id Patch ID calculation

1b329089

2017-05-31T22:27:19

config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.

28c2cc3d

2017-05-31T16:41:44

config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.

83bcd3a1

2017-05-31T22:45:25

config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.

56a7a264

2017-05-31T14:50:40

config_file: remove unused backend field from parse data The backend passed to `config_read` is never actually used anymore, so we can remove it from the function and the `parse_data` structure.

3a7f7a6e

2017-05-31T14:43:46

config_file: pass reader directly to callbacks Previously, the callbacks passed to `config_parse` got the reader via a pointer to a pointer. This allowed the callbacks to update the callers `reader` variable when the array holding it has been reallocated. As the array is no longer present, we can simply the code by making the reader a simple pointer.

73df75d8

2017-05-31T14:34:48

config_file: refactor include handling Current code for configuration files uses the `reader` structure to parse configuration files and store additional metadata like the file's path and checksum. These structures are stored within an array in the backend itself, which causes multiple problems. First, it does not make sense to keep around the file's contents with the backend itself. While this data is usually free'd before being added to the backend, this brings along somewhat intricate lifecycle problems. A better solution would be to store only the file paths as well as the checksum of the currently parsed content only. The second problem is that the `reader` structures are stored inside an array. When re-parsing configuration files due to changed contents, we may cause this array to be reallocated, requiring us to update pointers hold by callers. Furthermore, we do not keep track of includes which are already associated to a reader inside of this array. This causes us to add readers multiple times to the backend, e.g. in the scenario of refreshing configurations. This commit fixes these shortcomings. We introduce a split between the parsing data and the configuration file's metadata. The `reader` will now only hold the file's contents and the parser state and the new `config_file` structure holds the file's path and checksum. Furthermore, the new structure is a recursive structure in that it will also hold references to the files it directly includes. The diskfile is changed to only store the top-level configuration file. These changes allow us further refactorings and greatly simplify understanding the code.

6f7aab0c

2017-06-06T09:45:11

tests: config::include: use init and cleanup functions

8149f850

2017-07-14T08:30:18

Merge pull request #4306 from libgit2/cmn/tag-bad-signature signature: don't leave a dangling pointer to the strings on parse failure

d1dbb3ae

2017-07-12T07:40:16

signature: don't leave a dangling pointer to the strings on parse failure If the signature is invalid but we detect that after allocating the strings, we free them. We however leave that pointer dangling in the structure the caller gave us, which can lead to double-free. Set these pointers to `NULL` after freeing their memory to avoid this.

9093ced6

2017-07-10T11:42:26

patch_generate: represent buffers as void pointers Pointers to general data should usually be used as a void pointer such that it is possible to hand in variables of a different pointer type without the need to cast. This is the same when creating patches from buffers, where the buffers may contain arbitrary data. Instead of requiring the caller to care whether his buffer is e.g. `char *` or `unsigned char *`, we should instead just accept a `void *`. This is also consistent in how we tread other types like for example `git_blob`, which also just has a void pointer as its raw contents.

c4c95bf4

2017-07-10T08:50:11

Merge pull request #4287 from AndreyG/reset/interface-cosmetics git_reset_*: pass parameters as const pointers

0e165686

2017-07-07T10:03:34

Merge pull request #4291 from pks-t/pks/regex-header-confusion tests: config: fix missing declaration causing error

1f7af277

2017-07-05T11:52:47

tests: config: fix missing declaration causing error On systems where we pull in our distributed version of the regex library, all tests in config::readonly fail. This error is actually quite interesting: the test suite is unable to find the declaration of `git_path_exists` and assumes it has a signature of `int git_path_exists(const char *)`. But actually, it has a `bool` return value. Due to this confusion, some wrong conversion is done by the compiler and the `cl_assert(!git_path_exists("file"))` checks erroneously fail, even when the function does in fact return the correct value. The error is actually introduced by 56893bb9a (cmake: consistently use TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately introduced by myself. Due to the delayed addition of include directories, we will now find the "config.h" header inside of the "deps/regex" directory instead of inside the "src/" directory, where it should be. As such, we are missing definitions for the `git_config_file__ondisk` and `git_path_exists` symbols. The correct fix here would be to fix the order in which include search directories are added. But due to the current restructuring of CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a bit. Instead, we paper over the issue by explicitly including "path.h" to fix its prototype. This ignores the issue that `git_config_file__ondisk` is undeclared, as its signature is correctly identified by the compiler.

0c7f49dd

2017-06-30T13:39:01

Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.

2480d0eb

2017-06-30T13:34:05

Add missing license headers Some implementation files were missing the license headers. This commit adds them.

0fb4b351

2017-06-30T13:27:26

Fix missing include for header files Some of our header files are not included at all by any of their implementing counter-parts. Including them inside of these files leads to some compile errors mostly due to unknown types because of missing includes. But there's also one case where a declared function does not match the implementation's prototype. Fix all these errors by fixing up the prototype and adding missing includes. This is preparatory work for fixing up missing includes in the implementation files.

9b0482e4

2017-06-30T19:24:15

zlib: include "git2/types.h" instead of "common.h" The zlib dependency includes "common.h" inside of the "zconf.h" header to make available some type declarations like e.g. git_off_t. Including the "common.h" header does pull in quite a lot of other headers though, which are not required at all. Instead, we can just include our public "git2/types.h" header, which is much more limited in its scope but still provides everything required for "zconf.h". This fix eases the transition later on to use a separate "features.h" header instead of defines. As we have to generate the "features.h" header, we put it in the build directory and add an include directory. As we are splitting out building of dependencies into subdirectories, this would mean that the zlib dependency needs to be aware of the parent project's build directory, which is unfortunate. By including "git2/types.h", we avoid this problem.

459fb8fe

2017-06-30T15:35:46

win32: fix circular include deps with w32_crtdbg The current order of declarations and includes between "common.h" and "w32_crtdbg_stacktrace.h" is rather complicated. Both header files make use of things defined in the other one and are thus circularly dependent on each other. This makes it currently impossible to compile the "w32_crtdbg_stacktrace.c" file when including "common.h" inside of "w32_crtdbg_stacktrace.h". We can disentangle the mess by moving declaration of the inline crtdbg functions into the "w32_crtdbg_stacktrace.h" file and adding additional includes inside of it, such that all required functions are available to it. This allows us to break the dependency cycle.

d4e03be6

2017-06-30T11:21:18

git_reset_*: pass parameters as const pointers

c26ce784

2017-06-28T12:26:04

Merge branch 'AndreyG/cmake/modernization'

thodg/libgit2

Log