|
9dc21efd
|
2017-10-07T00:10:06
|
|
travis: add custom apt sources
Move back to Travis's VM infrastructure for efficiency.
|
|
62ac3931
|
2017-10-06T14:57:02
|
|
Merge pull request #4362 from jacwah/graphdoc
Document that a commit is not a descendant of itself
|
|
56ac6c0a
|
2017-09-30T17:23:11
|
|
graph: document that a commit isn't a descendant of itself
|
|
|
ec76cc48
|
2017-10-06T13:58:19
|
|
Merge pull request #4364 from andoma/master
Use SOCK_CLOEXEC when creating sockets
|
|
9fe70c9e
|
2017-01-20T23:14:19
|
|
Use SOCK_CLOEXEC when creating sockets
|
|
c7c5f2c4
|
2017-09-28T18:28:37
|
|
Merge pull request #4339 from pks-t/pks/static-linking
Static linking for bundled deps
|
|
366f4136
|
2017-09-28T17:19:56
|
|
travis: keep installing our custom libcurl build
The block in the script installs the packages if we're _not_ on Precise. This
was dropped in c17c3f8a ("travis: drop support for Ubuntu Precise") in error.
|
|
|
8c19969a
|
2017-09-06T07:38:48
|
|
cmake: fix static linking for bundled deps
Our bundled deps are being built as simple static libraries which are
then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While
this works for a dynamically built libgit2 library, using this function
to link two static libraries does not have the expected outcome of
merging those static libraries into one big library. This leads to
symbols of our bundled deps being undefined in the resulting libgit2
archive.
As we have bumped our minimum CMake version to 2.8.11, we can now easily
make use of object libraries for our bundled dependencies. So build
instructions are still self-contained inside of the dependency
directories and the resulting object libraries can just be added to the
LIBGIT2_OBJECTS list, which will cause them to be linked into the final
resulting static library. This fixes the issue of undefined symbols.
|
|
|
d8d2f21e
|
2017-09-06T07:52:12
|
|
cmake: unify version check for target include directories
There are two locations where we check whether CMake supports
`TARGET_INCLUDE_DIRECTORIES`. While the first one uses `VERSION_LESS
2.8.12`, the second one uses `VERSION_GREATER 2.8.11`, which are
obviously equivalent to each other. It'd still be easier to grep for
specific CMake versions being required for some features if both used
the same conditional mentioning the actual target version required. So
this commit refactors these conditions to make them equal.
|
|
|
172a585f
|
2017-09-05T15:09:34
|
|
cmake: always use object library for git2internal
As we have bumped our minimum CMake version to 2.8.11, we can now
unconditionally make use of object libraries. So remove the version
check for the git2internal object library and always use it.
|
|
|
cf9f3452
|
2017-09-06T07:38:32
|
|
cmake: bump minimum version to 2.8.11
Our current minimum CMake version is 2.8. This version does not yet
allow us to use object libraries (introduced in 2.8.8) and target
include directories (introduced in 2.8.12), which are both mechanisms we
want to use to fix some specific problems. We previously were not able
to bump our CMake version to a version supporting object libraries
because Ubuntu Precise only had CMake version 2.8.7 in its repositories.
But due to Precise being end of life now, we shouldn't need to honor it
anymore. A current survey of some of the more conservative distributions
brings up the following versions of CMake:
- CentOS 5: 2.6.2
- CentOS 6: 2.8.12.2
- Debian 7: 2.8.11
- Fedora 23: 3.3.2
- OpenSUSE 13.2: 3.0.2
- Ubuntu Precise: 2.8.7
- Ubuntu Trusty: 2.8.12
The only two outliers here are CentOS 5 and Ubuntu Precise. CentOS is
currently unsupported due to our minimum version being 2.8 and Ubuntu
Precise is not maintained anymore. So the next smallest version
supported by all major distributions is 2.8.11. While this does not yet
support target include directories, it at least enables us to use object
libraries. So this becomes our new minimum required version.
|
|
|
1d9dd882
|
2017-09-05T15:06:29
|
|
cmake: distinguish libgit2 objects and sources
Distinguish variables keeping track of our internal libgit2 sources and
the final objects which shall be linked into the library. This will ease
the transition to use object libraries for our bundled dependencies
instead of linking them in.
|
|
|
c17c3f8a
|
2017-09-06T08:04:19
|
|
travis: drop support for Ubuntu Precise
Ubuntu Precise is end of life since April 2017. At that point in time,
Precise was still the main distro on which Travis CI built upon, with
the Trusty-based images still being in a beta state. But since June
21st, Trusty has officially moved out of beta and is now the default
image for all new builds. Right now, we build on both old and new images
to assure we support both.
Unfortunately, this leaves us with the highest minimum version for CMake
being 2.8.7, as Precise has no greater version in its repositories. And
because of this limitation, we cannot actually use object libraries in
our build instructions. But considering Precise is end of life and
Trusty is now the new default for Travis, we can and should drop support
for this old and unmaintained distribution. And so we do.
|
|
|
524c1d3c
|
2017-09-20T07:48:19
|
|
Merge pull request #4334 from pks-t/pks/reproducible-builds
Reproducible builds
|
|
|
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.
|
|
|
d630887b
|
2017-08-30T21:47:12
|
|
cmake: enable reproducible static linking
By default, both ar(1) and ranlib(1) will insert additional information
like timestamps into generated static archives and indices. As a
consequence, generated static archives are not deterministic when
created with default parameters.
Both programs do support a deterministic mode, which will simply zero
out undeterministic information with `ar D` and `ranlib -D`.
Unfortunately, CMake does not provide an easy knob to add these command
line parameters. Instead, we have to redefine the complete command
definitons stored in the variables CMAKE_C_ARCHIVE_CREATE,
CMAKE_C_ARCHIVE_APPEND and CMAKE_C_ARCHIVE_FINISH.
Introduce a new build option `ENABLE_REPRODUCIBLE_BUILDS`. This option
is available on Unix-like systems with the exception of macOS, which
does not have support for the required flags. If the option is being
enabled, we add those flags to the invocation of both `ar` and `ranlib`
to enable deterministically building the static archive.
|
|
|
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.
|
|
|
583e4141
|
2017-08-30T14:35:57
|
|
tests: deterministically generate test suite definitions
The script "generate.py" is used to parse all test source files for unit
tests. These are then written into a "clar.suite" file, which can be
included by the main test executable to make available all test suites
and unit tests.
Our current algorithm simply collects all test suites inside of a dict,
iterates through its items and dumps them in a special format into the
file. As the order is not guaranteed to be deterministic for Python
dictionaries, this may result in arbitrarily ordered C structs. This
obviously defeats the purpose of reproducible builds, where the same
input should always result in the exact same output.
Fix this issue by sorting the test suites by name previous to dumping
them as structs. This enables reproducible builds for the libgit2_clar
file.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|