|
f063dafb
|
2017-11-12T10:56:50
|
|
signature: distinguish +0000 and -0000 UTC offsets
Git considers '-0000' a valid offset for signature lines. They need to
be treated as _not_ equal to a '+0000' signature offset. Parsing a
signature line stores the offset in a signed integer which does not
distinguish between `+0` and `-0`.
This patch adds an additional flag `sign` to the `git_time` in the
`signature` object which is populated with the sign of the offset. In
addition to exposing this information to the user, this information is
also used to compare signatures.
/cc @pks-t @ethomson
|
|
1d7c15ad
|
2017-11-11T20:15:07
|
|
Merge pull request #4310 from pks-t/pks/common-parser
Common parser interface
|
|
9e66590b
|
2017-07-21T13:01:43
|
|
config_parse: use common parser interface
As the config parser is now cleanly separated from the config file code,
we can easily refactor the code and make use of the common parser
module. This removes quite a lot of duplicated functionality previously
used for handling the actual parser state and replaces it with the
generic interface provided by the parser context.
|
|
|
1953c68b
|
2017-11-11T17:12:31
|
|
config_file: split out module to parse config files
The configuration file code grew quite big and intermingles both actual
configuration logic as well as the parsing logic of the configuration
syntax. This makes it hard to refactor the parsing logic on its own and
convert it to make use of our new parsing context module.
Refactor the code and split it up into two parts. The config file code
will only handle actual handling of configuration files, includes and
writing new files. The newly created config parser module is then only
responsible for parsing the actual contents of a configuration file,
leaving everything else to callbacks provided to its provided function
`git_config_parse`.
|
|
|
252f2eee
|
2017-07-14T13:45:05
|
|
parse: implement and use `git_parse_advance_digit`
The patch parsing code has multiple recurring patterns where we want to
parse an actual number. Create a new function `git_parse_advance_digit`
and use it to avoid code duplication.
|
|
|
65dcb645
|
2017-07-14T13:29:29
|
|
patch_parse: use git_parse_contains_s
Instead of manually checking the parsing context's remaining length and
comparing the leading bytes with a specific string, we can simply re-use
the function `git_parse_ctx_contains_s`. Do so to avoid code duplication
and to further decouple patch parsing from the parsing context's struct
members.
|
|
|
7bdfc0a6
|
2017-07-14T15:33:32
|
|
parse: always initialize line pointer
Upon initializing the parser context, we do not currently initialize the
current line, line length and line number. Do so in order to make the
interface easier to use and more obvious for future consumers of the
parsing API.
|
|
|
e72cb769
|
2017-07-14T14:37:07
|
|
parse: implement `git_parse_peek`
Some code parts need to inspect the next few bytes without actually
consuming it yet, for example to examine what content it has to expect
next. Create a new function `git_parse_peek` which returns the next byte
without modifying the parsing context and use it at multiple call sites.
|
|
|
ef1395f3
|
2017-11-11T15:30:43
|
|
parse: extract parse module
The `git_patch_parse_ctx` encapsulates both parser state as well as
options specific to patch parsing. To advance this state and keep it
consistent, we provide a few functions which handle advancing the
current position and accessing bytes of the patch contents. In fact,
these functions are quite generic and not related to patch-parsing by
themselves. Seeing that we have similar logic inside of other modules,
it becomes quite enticing to extract this functionality into its own
parser module.
To do so, we create a new module `parse` with a central struct called
`git_parse_ctx`. It encapsulates both the content that is to be parsed
as well as its lengths and the current position. `git_patch_parse_ctx`
now only contains this `parse_ctx` only, which is then accessed whenever
we need to touch the current parser. This is the first step towards
re-using this functionality across other modules which require parsing
functionality and remove code-duplication.
|
|
|
a0b0b808
|
2017-11-11T14:03:14
|
|
cmake: Allow user to select bundled zlib
Under some circumstances the installed / system version of zlib may not
be desirable due to being too old or buggy. This patch adds the option
`USE_BUNDLED_ZLIB` that will cause the bundled version of zlib to be
used.
We may also want to add similar functionality to allow the user to
select other bundled 3rd-party dependencies instead of using the system
versions.
/cc @pks-t @ethomson
|
|
|
0393ecc6
|
2017-11-11T13:29:27
|
|
Merge pull request #4308 from pks-t/pks/header-state-machine
patch_parse: implement state machine for parsing patch headers
|
|
|
88450c1c
|
2017-11-09T21:49:30
|
|
Merge pull request #4283 from tiennou/generic-tls
CMake: make HTTPS support more generic
|
|
8233f6e3
|
2017-11-04T23:34:14
|
|
Merge pull request #4386 from novalis/gitignore-ignore-space
ignore spaces in .gitignore files
|
|
42627933
|
2017-11-04T18:03:26
|
|
Merge remote-tracking branch 'upstream/master' into pks/conditional-includes
|
|
|
1475b981
|
2017-11-04T18:00:56
|
|
config: keep the output parameter at the start of the function
|
|
|
94e30d9b
|
2017-10-30T15:55:18
|
|
config: check for OOM when writing
|
|
|
8ec806d7
|
2017-10-30T06:23:31
|
|
config: preserve the original case when writing out new sections and vars
For sections we will still use the existing one even if the case disagrees, but
the variable always gets written with the case given by the caller.
|
|
5cb6a2c9
|
2017-10-29T12:28:43
|
|
Ignore trailing whitespace in .gitignore files (as git itself does)
|
|
|
79e09e1a
|
2017-10-29T13:16:09
|
|
Merge pull request #3944 from mhagger/diff-indent-heuristic
Implement a diff indent heuristic
|
|
|
1b9cc2ec
|
2017-10-29T12:08:00
|
|
Merge remote-tracking branch 'upstream/master' into diff-indent-heuristic
|
|
c9bb68c2
|
2017-09-07T00:41:54
|
|
cmake: move Darwin-specific block around
This allows us to only link against CoreFoundation when using the SecureTransport backend
|
|
|
9980be03
|
2017-09-06T22:13:58
|
|
cmake: Add USE_HTTPS as a CMake option
It defaults to ON, e.g. "pick whatever default is appropriate for the platform".
It accepts one of SecureTransport, OpenSSL, WinHTTP, or OFF.
It errors if the backend library couldn't be found.
|
|
|
fdd06874
|
2017-08-09T21:35:53
|
|
cmake: use FeatureSummary to display which features we end up using
|
|
|
99d6ebb3
|
2017-09-06T22:01:50
|
|
cmake: make our macOS helpers more CMake-y
|
|
|
766b4ddb
|
2017-07-02T16:11:13
|
|
https: correct some error messages
|
|
|
22317057
|
2017-03-21T00:36:32
|
|
https: Prevent OpenSSL from namespace-leaking
|
|
|
e9369856
|
2017-03-21T00:25:15
|
|
stream: Gather streams to src/streams
|
|
f2f14724
|
2017-09-21T15:51:52
|
|
transports: ssh: ask for credentials again when passphrase is wrong
When trying to decode the private key it looks like LibSSH2 returns a
LIBSSH2_ERROR_PUBLICKEY_UNVERIFIED when the passphrase is incorrect.
|
|
|
4da74c83
|
2017-10-20T07:29:17
|
|
cmake: use project-relative binary and source directories
Due to our split of CMake files into multiple modules, we had to replace
some uses of the `${CMAKE_CURRENT_SOURCE_DIR}` and
`${CMAKE_CURRENT_BINARY_DIR}` variables and replace them with
`${CMAKE_SOURCE_DIR}` and `${CMAKE_BINARY_DIR}`. This enabled us to
still be able to refer to top-level files when defining build
instructions inside of a subdirectory.
When replacing all variables, it was assumed that the absolute set of
variables is always relative to the current project. But in fact, this
is not the case, as these variables always point to the source and
binary directory as given by the top-levl project. So the change
actually broke the ability to include libgit2 directly as a subproject,
as source files cannot be found anymore.
Fix this by instead using project-specific source and binary directories
with `${libgit2_SOURCE_DIR}` and `${libgit2_BINARY_DIR}`.
|
|
5efe9d12
|
2017-10-14T08:58:14
|
|
Introduce a new `XDL_INLINE` macro and use it instead of `inline`
`inline` is not portable enough, and the `xdiff` code doesn't import
the `GIT_INLINE` macro. So introduce a new `XDL_INLINE` macro (with
the same definition as `GIT_INLINE`). Use the new macro to inline two
functions in `xdiffi.c`.
|
|
|
34ec6f3a
|
2017-10-09T15:01:29
|
|
Merge pull request #4372 from pks-t/pks/xcode-linking
cmake: fix linking in Xcode with object libraries only
|
|
|
9840dad2
|
2017-10-09T14:57:33
|
|
Merge pull request #4368 from pks-t/pks/smart-negotiate-revwalk-memleak
transports: smart: fix memory leak when skipping symbolic refs
|
|
|
f7d837c8
|
2017-05-24T12:12:29
|
|
config_file: implement "gitdir/i" conditional
Next to the "gitdir" conditional for including other configuration
files, there's also a "gitdir/i" conditional. In contrast to the former
one, path matching with "gitdir/i" is done case-insensitively. This
commit implements the case-insensitive condition.
|
|
|
071b6c06
|
2017-05-24T11:13:36
|
|
config_file: implement conditional "gitdir" includes
Upstream git.git has implemented the ability to include other
configuration files based on conditions. Right now, this only includes
the ability to include a file based on the gitdir-location of the
repository the currently parsed configuration file belongs to. This
commit implements handling these conditional includes for the
case-sensitive "gitdir" condition.
|
|
|
9d7a75be
|
2017-08-25T19:15:00
|
|
config_file: make repo and config path accessible to reader
The reader machinery will be extended to handle conditional includes.
The only conditions that currently exist all match the against the git
directory of the repository the config file belongs to. As such, we need
to have access to the repository when reading configuration files to
properly handle these conditions.
One specialty of thes conditional includes is that the actual pattern
may also be a relative pattern starting with "./". In this case, we have
to match the pattern against the path relative to the config file which
is currently being parsed. So besides the repository, we also have to
pass down the path to the current config file that is being parsed.
|
|
|
d5b9d9e9
|
2017-05-23T10:53:49
|
|
config_file: extract function to parse include path
The logic inside this function will be required later on, when
implementing conditional includes. Extract it into its own function to
ease the implementation.
|
|
|
529e873c
|
2017-05-23T11:51:00
|
|
config: pass repository when opening config files
Our current configuration logic is completely oblivious of any
repository, but only cares for actual file paths. Unfortunately, we are
forced to break this assumption by the introduction of conditional
includes, which are evaluated in the context of a repository. Right now,
only one conditional exists with "gitdir:" -- it will only include the
configuration if the current repository's git directory matches the
value passed to "gitdir:".
To support these conditionals, we have to break our API and make the
repository available when opening a configuration file. This commit
extends the `open` call of configuration backends to include another
repository and adjusts existing code to have it available. This includes
the user-visible functions `git_config_add_file_ondisk` and
`git_config_add_backend`.
|
|
|
d02cf564
|
2017-05-23T12:56:41
|
|
repository: constify several repo parameters for getters
Several functions to retrieve variables from a repository only return
immutable values, which allows us to actually constify the passed-in
repository parameter. Do so to help a later patch, which will only have
access to a constant repository.
|
|
|
f38ce9b6
|
2017-05-24T11:09:38
|
|
path: expose `git_path_is_dirsep`
This function has previously been implemented in Windows-specific path
handling code as `path__is_dirsep`. As we will need this functionality
in other parts, extract the logic into "path.h" alongside with a
non-Windows implementation.
|
|
|
e54cf1a3
|
2017-05-24T11:07:20
|
|
path: expose `git_path_is_absolute`
This function has previously been implemented in Windows-specific path
handling code as `path__is_absolute`. As we will need this functionality
in other parts, extract the logic into "path.h" alongside with a
non-Windows implementation.
|
|
|
0e709032
|
2017-10-09T10:55:02
|
|
cmake: fix linking in Xcode with object libraries only
CMake is unable to generate a correct Xcode project when trying to link
libraries with only object libraries as its input. As our new build
infrastructure makes heavy use of object libraries now, this affects our
libgit2 library target, as well, leading to linking errors.
Fix the issue by adding a dummy file to the libgit2 objects. As we
always have the "features.h" header ready which contains defines only,
we can simply link it into the resulting library without any effect
whatsoever. This fixes building with Xcode.
|
|
|
38e769cb
|
2017-10-09T09:00:29
|
|
Merge pull request #4369 from libgit2/ethomson/checkout_typechange
Checkout typechange-only deltas
|
|
|
7cb705cb
|
2017-10-06T12:05:26
|
|
transports: smart: fix memory leak when skipping symbolic refs
When we setup the revision walk for negotiating references with a
remote, we iterate over all references, ignoring tags and symbolic
references. While skipping over symbolic references, we forget to free
the looked up reference, resulting in a memory leak when the next
iteration simply overwrites the variable.
Fix that issue by freeing the reference at the beginning of each
iteration and collapsing return paths for error and success.
|
|
|
21e6a11a
|
2017-10-07T12:55:16
|
|
Merge pull request #4359 from libgit2/cmn/proxy-options-free
Plug some leaks in curl's proxy handling
|
|
|
128c5ca9
|
2017-10-07T12:23:33
|
|
checkout: do not test file mode on Windows
On Windows, we do not support file mode changes, so do not test
for type changes between the disk and tree being checked out.
We could have false positives since the on-disk file can only have
an (effective) mode of 0100644 since NTFS does not support executable
files. If the tree being checked out did have an executable file,
we would erroneously decide that the file on disk had been changed.
|
|
|
25fdb3f0
|
2017-10-07T11:25:12
|
|
proxy: rename the options freeing function
|
|
|
e2e3943d
|
2017-10-07T00:22:22
|
|
Merge pull request #4367 from pks-t/pks/peel-peeled-to-tag
refs: do not use peeled OID if peeling to a tag
|
|
752b7c79
|
2016-06-15T02:00:35
|
|
checkout: treat files as modified if mode differs
When performing a forced checkout, treat files as modified when the
workdir or the index is identical except for the mode. This ensures
that force checkout will update the mode to the target. (Apply this
check for regular files only, if one of the items was a file and the
other was another type of item then this would be a typechange and
handled independently.)
|
|
|
b112b1e9
|
2017-10-06T11:24:11
|
|
refs: do not use peeled OID if peeling to a tag
If a reference stored in a packed-refs file does not directly point to a
commit, tree or blob, the packed-refs file will also will include a
fully-peeled OID pointing to the first underlying object of that type.
If we try to peel a reference to an object, we will use that peeled OID
to speed up resolving the object.
As a reference for an annotated tag does not directly point to a commit,
tree or blob but instead to the tag object, the packed-refs file will
have an accomodating fully-peeled OID pointing to the object referenced
by that tag. When we use the fully-peeled OID pointing to the referenced
object when peeling, we obviously cannot peel that to the tag anymore.
Fix this issue by not using the fully-peeled OID whenever we want to
peel to a tag. Note that this does not include the case where we want to
resolve to _any_ object type. Existing code may make use from the fact
that we resolve those to commit objects instead of tag objects, even
though that behaviour is inconsistent between packed and loose
references. Furthermore, some tests of ours make the assumption that we
in fact resolve those references to a commit.
|
|
9fe70c9e
|
2017-01-20T23:14:19
|
|
Use SOCK_CLOEXEC when creating sockets
|
|
|
6f8d1eb9
|
2017-09-27T15:30:19
|
|
curl: free the user-provided proxy credentials
|
|
|
406b47bf
|
2017-09-27T15:27:32
|
|
curl: free the proxy options
|
|
|
44527f5c
|
2017-09-27T15:17:26
|
|
proxy: add a free function for the options's pointers
When we duplicate a user-provided options struct, we're stuck with freeing the
url in it. In case we add stuff to the proxy struct, let's add a function in
which to put the logic.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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()
|
|
|
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.
|
|
|
cc4c44a9
|
2017-09-01T09:37:05
|
|
patch_parse: fix parsing patches only containing exact renames
Patches which contain exact renames only will not contain an actual diff
body, but only a list of files that were renamed. Thus, the patch header
is immediately followed by the terminating sequence "-- ". We currently
do not recognize this character sequence as a possible terminating
sequence. Add it and create a test to catch the failure.
|
|
|
3c216453
|
2017-08-25T21:06:46
|
|
Merge pull request #4296 from pks-t/pks/pattern-based-gitignore
Fix negative ignore rules with patterns
|
|
|
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.
|
|
|
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.
|
|
|
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
|
|
|
57bc9dab
|
2017-07-14T10:57:49
|
|
patch_parse: implement state machine for parsing patch headers
Our code parsing Git patch headers is rather lax in parsing headers of a
Git-style patch. Most notably, we do not care for the exact order in
which header lines appear and as such, we may parse patch files which
are not really valid after all. Furthermore, the state transitions
inside of the parser are not as obvious as they could be, making it
harder than required to follow its logic.
To improve upon this situation, this patch introduces a real state
machine to parse the patches. Instead of simply parsing each line
without caring for previous state and the exact ordering, we define a
set of states with their allowed transitions. This makes the patch
parser more strict in only allowing valid successions of header lines.
As the transition table is defined inside of a single structure with
the expected line, required state as well as the state that we end up
in, all state transitions are immediately obvious from just having a
look at this structure. This improves both maintainability and eases
reasoning about the patch parser.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
1560b580
|
2017-08-15T10:35:47
|
|
Merge pull request #4288 from pks-t/pks/include-fixups
Include fixups
|
|
|
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
|
|
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
|
|
|
fb585d01
|
2017-07-31T00:58:58
|
|
Merge branch '4233'
|
|
|
ed00ac06
|
2017-07-26T23:24:28
|
|
Merge pull request #4314 from pks-t/pks/timsort
tsort: remove idempotent conditional assignment
|
|
|
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.
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|