|
cc8a9892
|
2019-04-16T18:13:31
|
|
config_file: check result of git_array_alloc
git_array_alloc can return NULL if no memory is available, causing
a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC
similar to how other parts of the code base deal with the return
value of git_array_alloc.
|
|
ed959ca2
|
2019-04-16T12:36:24
|
|
Merge pull request #5027 from ddevault/master
patch_parse.c: Handle CRLF in parse_header_start
|
|
d1cfd79a
|
2019-04-08T08:20:35
|
|
Merge pull request #5045 from cheese1/patch-1
fix typo
|
|
67562b23
|
2019-04-07T16:45:45
|
|
fix typo
|
|
|
c4cd69b2
|
2019-04-07T19:10:16
|
|
Merge pull request #5039 from libgit2/ethomson/win32_hash
sha1: don't inline `git_hash_global_init` for win32
|
|
|
5a190ad3
|
2019-04-07T19:07:42
|
|
Merge pull request #5040 from pks-t/pks/ignore-treat-dirpaths-as-dir
ignore: treat paths with trailing "/" as directories
|
|
30c06b60
|
2019-03-22T23:56:10
|
|
patch_parse.c: Handle CRLF in parse_header_start
|
|
|
9d117e20
|
2019-04-05T10:22:46
|
|
ignore: treat paths with trailing "/" as directories
The function `git_ignore_path_is_ignored` is there to test the
ignore status of paths that need not necessarily exist inside of
a repository. This has the implication that for a given path, we
cannot always decide whether it references a directory or a file,
and we need to distinguish those cases because ignore rules may
treat those differently. E.g. given the following gitignore file:
*
!/**/
we'd only want to unignore directories, while keeping files
ignored. But still, calling `git_ignore_path_is_ignored("dir/")`
will say that this directory is ignored because it treats "dir/"
as a file path.
As said, the `is_ignored` function cannot always decide whether
the given path is a file or directory, and thus it may produce
wrong results in some cases. While this is unfixable in the
general case, we can do better when we are being passed a path
name with a trailing path separator (e.g. "dir/") and always
treat them as directories.
|
|
|
aeea1c46
|
2019-04-04T15:06:44
|
|
Merge pull request #4874 from tiennou/test/4615
Test that largefiles can be read through the tree API
|
|
|
80db2043
|
2019-04-04T14:16:44
|
|
Merge pull request #5034 from pks-t/pks/symlinked-user-config
Tests for symlinked user config
|
|
|
6bcb7357
|
2019-04-04T14:04:59
|
|
Merge pull request #5035 from pks-t/pks/diff-with-space-in-filenames
patch_parse: fix parsing addition/deletion of file with space
|
|
|
fb7614c0
|
2019-04-04T13:51:52
|
|
tests: test largefiles on win32
|
|
|
18e836cb
|
2019-04-04T10:55:38
|
|
Merge pull request #5018 from romkatv/strings
Optimize string comparisons
|
|
|
e5aecaf6
|
2019-04-04T18:45:30
|
|
sha1: don't inline `git_hash_global_init` for win32
Users of the Win32 hash cannot be inlined, as it uses a static struct.
Don't inline it, but continue to declare the function in the header.
|
|
30a56ba6
|
2019-03-14T14:54:47
|
|
optimize string comparisons
|
|
|
9aa049d4
|
2019-03-29T13:28:59
|
|
Merge pull request #5020 from implausible/fix/gitignore-negation
Negation of subdir ignore causes other subdirs to be unignored
|
|
|
8cf3fd93
|
2019-03-29T11:23:29
|
|
tests: config: assure that we can read symlinked global configuration
According to reports, libgit2 is unable to read a global configuration
file that is simply a symlink to the real configuration. Write a
(succeeding) test that shows that libgit2 _is_ correctly able to do so.
|
|
|
b3ba2e71
|
2019-03-29T11:15:26
|
|
tests: config: verify that the global config is actually readable
While we do verify that we are able to open the global ".gitconfig" file
in config::global::open_global, we never verify that we it is in fact
readable. Do so by writing the global configuration file and verifying
that reading from it produces the expected values.
|
|
|
25c085e6
|
2019-03-29T11:41:42
|
|
tests: repo: verify that we can open repos with symlinked global config
We've got reports that users are unable to open repos when their global
configuration ("~/.gitconfig") is a symlink. Add a test to verify that
we are in fact able to do so as expected.
|
|
9d65360b
|
2019-03-29T12:30:37
|
|
tests: diff: test parsing diffs with a new file with spaces in its path
Add a test that verifies that we are able to parse patches which add a
new file that has spaces in its path.
|
|
|
b3497344
|
2019-03-29T12:15:20
|
|
patch_parse: fix parsing addition/deletion of file with space
The diff header format is a strange beast in that it is inherently
unparseable in an unambiguous way. While parsing
a/file.txt b/file.txt
is obvious and trivially doable, parsing a diff header of
a/file b/file ab.txt b/file b/file ab.txt
is not (but in fact valid and created by git.git).
Due to that, we have relaxed our diff header parser in commit 80226b5f6
(patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so
that we started to bail out when seeing diff headers with spaces in
their file names. Instead, we try to use the "---" and "+++" lines,
which are unambiguous.
In some cases, though, we neither have a useable file name from the
header nor from the "---" or "+++" lines. This is the case when we have
a deletion or addition of a file with spaces: the header is unparseable
and the other lines will simply show "/dev/null". This trips our parsing
logic when we try to extract the prefix (the "a/" part) that is being
used in the path line, where we unconditionally try to dereference a
NULL pointer in such a scenario.
We can fix this by simply not trying to parse the prefix in cases where
we have no useable path name. That'd leave the parsed patch without
either `old_prefix` or `new_prefix` populated. But in fact such cases
are already handled by users of the patch object, which simply opt to
use the default prefixes in that case.
|
|
|
131cd9b1
|
2019-03-29T11:58:50
|
|
patch_parse: improve formatting
|
|
|
5f188c48
|
2019-03-29T11:52:39
|
|
Merge pull request #5024 from stewid/xdiff-fix-typo
xdiff: fix typo
|
|
|
fa4505e6
|
2019-03-29T11:30:29
|
|
tests: config: make sure to clean up after each test
The config::global test suite creates various different directories and
files which are being populated with pretend-global files.
Unfortunately, the tests do not clean up after themselves, which may
cause subsequent tests to fail due to cruft left behind.
Fix this by always removing created directories and their contents.
|
|
|
675251d1
|
2019-03-28T20:35:17
|
|
Merge pull request #5032 from eaigner/checkout-force-safe-docfix
docs: clarify relation of safe and forced checkout strategy
|
|
|
bbba4805
|
2019-03-25T20:45:58
|
|
docs: clarify relation of safe and forced checkout strategy
|
|
|
7f1ba196
|
2019-03-24T17:41:24
|
|
Merge pull request #5026 from tenderlove/define-hash-global-init-consnstently
Each hash implementation should define `git_hash_global_init`
|
|
be9a386c
|
2019-03-22T17:04:32
|
|
Each hash implementation should define `git_hash_global_init`
This means the forward declaration isn't necessary. The forward
declaration can cause compilation errors as it conflicts with the
`GIT_INLINE` declaration (the signatures are different).
|
|
d87441f2
|
2019-03-20T13:24:07
|
|
ignore: move tests from status to attr ignore suite
|
|
1a349003
|
2019-03-20T21:20:01
|
|
xdiff: fix typo
|
|
|
b50e448b
|
2019-03-15T13:08:18
|
|
ignore: add additional test cases
|
|
|
e3d7bccb
|
2019-03-14T15:51:15
|
|
ignore: Do not match on prefix of negated patterns
Matching on the prefix of a negated pattern was triggering false
negatives on siblings of that pattern. e.g.
Given the .gitignore:
dir/*
!dir/sub1/sub2/**
The path `dir/a.text` would not be ignored.
|
|
bc74c53a
|
2019-03-14T09:59:27
|
|
Implement failing test for gitignore of complex subdirectory negation
When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored
|
|
|
8e4927a4
|
2019-03-06T09:13:56
|
|
Merge pull request #5012 from dritter/dritter-patch-1
[Doc] Update URL to git2-rs
|
|
1fd0903a
|
2019-03-05T18:47:45
|
|
Update URL to git2-rs
|
|
|
79b26f20
|
2019-03-02T18:21:47
|
|
Merge pull request #5008 from libgit2/ethomson/remote_completion
remote: Rename git_remote_completion_type to _t
|
|
|
7b083d3c
|
2019-03-02T18:14:36
|
|
Merge pull request #5005 from libgit2/ethomson/odb_backend_allocations
odb: provide a free function for custom backends
|
|
|
c7e5eca6
|
2019-02-28T10:46:26
|
|
Revert "foo"
This reverts commit 1fe3fa5e59818c851d50efc6563db5f8a5d7ae9b.
|
|
|
1fe3fa5e
|
2019-02-28T10:44:34
|
|
foo
|
|
|
b401273b
|
2019-02-27T10:08:28
|
|
Merge branch 'threading-docs'
|
|
|
02ab4841
|
2019-02-27T10:08:15
|
|
threading: clarify openssl default vs mbedtls
|
|
|
358a3b9c
|
2019-02-27T10:08:00
|
|
threading: clarify concurrency of access
|
|
|
2dd5a429
|
2019-02-25T13:16:13
|
|
remote: Rename git_remote_completion_type to _t
For consistency with other "type" enums, rename
git_remote_completion_type to git_remote_completion_t.
|
|
|
68729289
|
2019-02-25T09:25:34
|
|
Merge pull request #5000 from augfab/branch_lookup_all
Have git_branch_lookup accept GIT_BRANCH_ALL
|
|
|
459ac856
|
2019-02-23T18:42:53
|
|
odb: provide a free function for custom backends
Custom backends can allocate memory when reading objects and providing
them to libgit2. However, if an error occurs in the custom backend
after the memory has been allocated for the custom object but before
it's returned to libgit2, the custom backend has no way to free that
memory and it must be leaked.
Provide a free function that corresponds to the alloc function so that
custom backends have an opportunity to free memory before they return an
error.
|
|
|
790aae77
|
2019-02-23T18:40:43
|
|
odb: rename git_odb_backend_malloc for consistency
The `git_odb_backend_malloc` name is a system function that is provided
for custom ODB backends and allows them to allocate memory for an ODB
object in the read callback. This is important so that libgit2 can
later free the memory used by an ODB object that was read from the
custom backend.
However, the name _suggests_ that it actually allocates a
`git_odb_backend`. It does not; rename it to make it clear that it
actually allocates backend _data_.
|
|
c5d8e300
|
2019-02-21T21:46:39
|
|
branch: have git_branch_lookup accept GIT_BRANCH_ALL
|
|
|
0a25141e
|
2019-02-21T21:42:25
|
|
branch: add test for git_branch_lookup to accept GIT_BRANCH_ALL
|
|
|
bd132046
|
2019-02-22T20:10:52
|
|
p_fallocate: compatibility fixes for macOS
On macOS, fcntl(..., F_PREALLOCATE, ...) will only succeed when followed
by an ftruncate(), even when it reports success.
However, that syscall will fail when the file already exists. Thus, we
must ignore the error code and simply let ftruncate extend the size of
the file itself (albeit slowly).
By calling ftruncate, we also need to prevent against file shrinkage,
for compatibility with posix_ftruncate, which will only extend files,
never shrink them.
|
|
|
0345a380
|
2019-02-22T14:39:08
|
|
p_fallocate: add a test for our implementation
|
|
|
7ab7bf46
|
2019-02-22T11:32:01
|
|
p_fallocate: don't duplicate definitions for win32
|
|
|
32f50452
|
2019-02-22T11:22:28
|
|
p_fallocate: add Windows emulation
Emulate `p_fallocate` on Windows by seeking beyond the end of the file
and setting the size to the current seek position.
|
|
|
5a6a3c00
|
2019-02-22T11:45:42
|
|
Merge pull request #4997 from libgit2/ethomson/transfer_progress
Rename git_transfer_progress to git_indexer_progress
|
|
|
ca909da5
|
2019-02-21T11:45:23
|
|
remote: deprecate git_push_transfer_progress
Safely deprecate `git_push_transfer_progress`, forwarding it to the new
`git_push_transfer_progress_cb` name.
|
|
|
59001e83
|
2019-02-21T11:41:19
|
|
remote: rename git_push_transfer_progress callback
The `git_push_transfer_progress` is a callback and as such should be
suffixed with `_cb` for consistency. Rename
`git_push_transfer_progress` to `git_push_transfer_progress_cb`.
|
|
|
7506d34c
|
2019-02-21T10:38:53
|
|
indexer: deprecate git_transfer_progress
Safely deprecate `git_transfer_progress` and `git_transfer_progress_cb`
types, forwarding them to the new `git_indexer_progress` and
`git_indexer_progress_cb`.
|
|
|
a1ef995d
|
2019-02-21T10:33:30
|
|
indexer: use git_indexer_progress throughout
Update internal usage of `git_transfer_progress` to
`git_indexer_progreses`.
|
|
|
975d6722
|
2019-02-21T10:13:29
|
|
indexer: rename git_transfer_progress
The name `git_transfer_progress` does not reflect its true purpose.
It suggests that it's progress for a non-existence `git_transfer`
object, and is used for indexing callbacks more broadly than just
during transfers.
Rename `git_transfer_progress` to `git_indexer_progress`.
|
|
|
4069f924
|
2019-02-22T10:56:08
|
|
Merge pull request #4901 from pks-t/pks/uniform-map-api
High-level map APIs
|
|
|
75dd7f2a
|
2019-02-22T10:13:00
|
|
Merge pull request #4984 from pks-t/pks/refdb-fs-race
refdb_fs: fix loose/packed refs lookup racing with repacks
|
|
|
c5594852
|
2019-02-22T10:06:24
|
|
Merge pull request #4998 from pks-t/pks/allocator-restructuring
Allocator restructuring
|
|
|
3aa8401a
|
2019-02-21T14:10:43
|
|
Merge pull request #4992 from pks-t/pks/cache-dispose
cache: fix misnaming of `git_cache_free`
|
|
|
68ba2e8d
|
2019-02-21T13:42:18
|
|
Merge pull request #4956 from pks-t/pks/examples-cgit2-standalone
examples: produce single cgit2 binary
|
|
|
bbdcd450
|
2019-02-20T10:40:06
|
|
cache: fix misnaming of `git_cache_free`
Functions that free a structure's contents but not the structure
itself shall be named `dispose` in the libgit2 project, but the
function `git_cache_free` does not follow this naming pattern.
Fix this by renaming it to `git_cache_dispose` and adjusting all
callers to make use of the new name.
|
|
|
765ff6e0
|
2019-02-21T12:35:48
|
|
allocators: make crtdbg allocator reuse its own realloc
In commit 6e0dfc6ff (Make stdalloc__reallocarray call
stdalloc__realloc, 2019-02-16), we have changed the stdalloc
allocator to reuse `stdalloc__realloc` to implement
`stdalloc__reallocarray`. This commit is making the same change
for the Windows-specific crtdbg allocator to avoid code
duplication.
|
|
|
48727e5d
|
2019-02-21T12:27:42
|
|
allocators: extract crtdbg allocator into its own file
The Windows-specific crtdbg allocator is currently mixed into the
crtdbg stacktracing compilation unit, making it harder to find
than necessary. Extract it and move it into the new "allocators/"
subdirectory to improve discoverability.
This change means that the crtdbg compilation unit is now
compiled unconditionally, whereas it has previously only been
compiled on Windows platforms. Thus we now have additional guards
around the code so that it will only be compiled if
GIT_MSVC_CRTDBG is defined. This also allows us to move over the
fallback-implementation of `git_win32_crtdbg_init_allocator` into
the same compilation unit.
|
|
|
b63396b7
|
2019-02-21T12:13:59
|
|
allocators: move standard allocator into subdirectory
Right now, our two allocator implementations are scattered around
the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h".
Start grouping them together in a single directory "allocators/",
similar to how e.g. our streams are organized.
|
|
|
9eb098d8
|
2019-02-21T11:37:04
|
|
Merge pull request #4991 from libgit2/ethomson/inttypes
Remove public 'inttypes.h' header
|
|
|
247e6d90
|
2019-02-18T07:22:20
|
|
Remove public 'inttypes.h' header
Remove an `inttypes.h` header that is too large in scope, and far too
public.
For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need
to include `stdint.h` in our public headers, for types like `uint32_t`.
Internally, we also need to define `PRId64` as a printf formatting
string when it is not available.
|
|
|
554b3b9a
|
2019-02-21T10:31:21
|
|
Merge pull request #4996 from eaigner/master
Prevent reading out of bounds memory
|
|
|
966b9440
|
2019-02-21T08:30:22
|
|
tests: apply: verify that we correctly truncate the source buffer
Previously, we would fail to correctly truncate the source buffer
if the source has more than one line and ends with a non-newline
character. In the following call, we thus truncate the source
string in the middle of the second line. Without the bug fixed,
we would successfully apply the patch to the source and return
success. With the overflow being fixed, we should return an
error now.
|
|
|
014d4955
|
2019-02-20T15:30:11
|
|
apply: prevent OOB read when parsing source buffer
When parsing the patch image from a string, we split the string
by newlines to get a line-based view of it. To split, we use
`memchr` on the buffer and limit the buffer length by the
original length provided by the caller. This works just fine for
the first line, but for every subsequent line we need to actually
subtract the amount of bytes that we have already read.
The above issue can be easily triggered by having a source buffer
with at least two lines, where the second line does _not_ end in
a newline. Given a string "foo\nb", we have an original length of
five bytes. After having extracted the first line, we will point
to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an
out-of-bounds read of four bytes.
Fix the issue by correctly subtracting the amount of bytes
already read.
|
|
|
6eb4947d
|
2019-02-21T08:02:45
|
|
Merge pull request #4987 from lhchavez/fix-odb_otype_fast-leak
Fix a memory leak in odb_otype_fast()
|
|
6b3730d4
|
2019-02-16T19:55:30
|
|
Fix a memory leak in odb_otype_fast()
This change frees a copy of a cached object in odb_otype_fast().
|
|
|
12c6e1fa
|
2019-02-20T10:54:00
|
|
Merge pull request #4986 from lhchavez/realloc
Make stdalloc__reallocarray call stdalloc__realloc
|
|
|
9f388e9f
|
2019-02-20T10:51:33
|
|
Merge pull request #4990 from libgit2/remove_time_monotonic
Remove `git_time_monotonic`
|
|
|
d900dde4
|
2019-02-20T10:37:20
|
|
Merge pull request #4988 from lhchavez/fix-improbable-odb-initialization-leak
Fix a _very_ improbable memory leak in git_odb_new()
|
|
|
e6c6d3bb
|
2019-02-17T22:31:37
|
|
Remove `git_time_monotonic`
`git_time_monotonic` was added so that non-native bindings like rugged
could get high-resolution timing for benchmarking. However, this is
outside the scope of libgit2 *and* rugged decided not to use this
function in the first place.
Google suggests that absolutely _nobody_ is using this function and we
don't want to be in the benchmarking business. Remove the function.
|
|
|
cb150e60
|
2019-02-17T19:31:11
|
|
Merge pull request #4989 from libgit2/ethomson/ci_docs
ci: publish documentation on merge
|
|
|
fbfa41a1
|
2019-02-17T19:07:37
|
|
ci: publish documentation on merge
When a commit is pushed or merged into one of the release branches
(master, maint/*) then push the documentation update to gh-pages.
|
|
|
b5b3aa93
|
2019-02-17T12:50:51
|
|
Revert "ci: publish documentation after merge"
This reverts commit 2a4e866a43e3db1e2be8e2a3d986ddc9f855d2bc.
|
|
|
4a02d24a
|
2019-02-17T12:40:20
|
|
foo
|
|
|
484fff87
|
2019-02-17T12:36:41
|
|
foo
|
|
|
2a4e866a
|
2019-02-17T12:34:23
|
|
ci: publish documentation after merge
When a continuous integration build runs (ie a commit is pushed or
merged into one of the CI branches, `master` or `maint/*`) then push the
rebuilt documentation into the `gh-pages` branch.
|
|
|
dd45539d
|
2019-02-16T22:06:58
|
|
Fix a _very_ improbable memory leak in git_odb_new()
This change fixes a mostly theoretical memory leak in got_odb_new()
that can only manifest if git_cache_init() fails due to running out of
memory or not being able to acquire its lock.
|
|
|
6e0dfc6f
|
2019-02-16T20:26:17
|
|
Make stdalloc__reallocarray call stdalloc__realloc
This change avoids calling realloc(3) in more than one place.
|
|
|
df42f368
|
2018-12-01T10:54:57
|
|
idxmap: remove legacy low-level interface
Remove the low-level interface that was exposing implementation details of
`git_idxmap` to callers. From now on, only the high-level functions shall be
used to retrieve or modify values of a map. Adjust remaining existing callers.
|
|
|
bd66925a
|
2018-12-01T10:29:32
|
|
oidmap: remove legacy low-level interface
Remove the low-level interface that was exposing implementation details of
`git_oidmap` to callers. From now on, only the high-level functions shall be
used to retrieve or modify values of a map. Adjust remaining existing callers.
|
|
|
4713e7c8
|
2018-12-01T09:58:30
|
|
offmap: remove legacy low-level interface
Remove the low-level interface that was exposing implementation details of
`git_offmap` to callers. From now on, only the high-level functions shall be
used to retrieve or modify values of a map. Adjust remaining existing callers.
|
|
|
fdfabdc4
|
2018-12-01T09:49:10
|
|
strmap: remove legacy low-level interface
Remove the low-level interface that was exposing implementation details of
`git_strmap` to callers. From now on, only the high-level functions shall be
used to retrieve or modify values of a map. Adjust remaining existing callers.
|
|
|
6a9117f5
|
2018-12-01T10:18:42
|
|
cache: use iteration interface for cache eviction
To relieve us from memory pressure, we may regularly call `cache_evict_entries`
to remove some entries from it. Unfortunately, our cache does not support a
least-recently-used mode or something similar, which is why we evict entries
completeley at random right now. Thing is, this is only possible due to the map
interfaces exposing the entry indices, and we intend to completely remove those
to decouple map users from map implementations. As soon as that is done, we are
unable to do this random eviction anymore.
Convert this to make use of an iterator for now. Obviously, there is no random
eviction possible like that anymore, but we'll always start by evicting from the
beginning of the map. Due to hashing, one may hope that the selected buckets
will be evicted at least in some way unpredictably. But more likely than not,
this will not be the case. But let's see what happens and if any users complain
about degraded performance. If so, we might come up with a different scheme than
random removal, e.g. by using an LRU cache.
|
|
|
c976b4f9
|
2018-12-01T10:18:26
|
|
indexer: use map iterator to delete expected OIDs
To compute whether there are objects missing in a packfile, the indexer keeps
around a map of OIDs that it still expects to see. This map does not store any
values at all, but in fact the keys are owned by the map itself. Right now, we
free these keys by iterating over the map and freeing the key itself, which is
kind of awkward as keys are expected to be constant.
We can make this a bit prettier by inserting the OID as value, too. As we
already store the `NULL` pointer either way, this does not increase memory
usage, but makes the code a tad more clear. Furthermore, we convert the
previously existing map iteration via indices to make use of an iterator,
instead.
|
|
|
18cf5698
|
2018-12-01T09:37:40
|
|
maps: provide high-level iteration interface
Currently, our headers need to leak some implementation details of maps due to
their direct use of indices in the implementation of their foreach macros. This
makes it impossible to completely hide the map structures away, and also makes
it impossible to include the khash implementation header in the C files of the
respective map only.
This is now being fixed by providing a high-level iteration interface
`map_iterate`, which takes as inputs the map that shall be iterated over, an
iterator as well as the locations where keys and values shall be put into. For
simplicity's sake, the iterator is a simple `size_t` that shall initialized to
`0` on the first call. All existing foreach macros are then adjusted to make use
of this new function.
|
|
|
c50a8ac2
|
2018-12-01T08:59:24
|
|
maps: use high-level function to check existence of keys
Some callers were still using the tightly-coupled pattern of `lookup_index` and
`valid_index` to verify that an entry exists in a map. Instead, use the more
high-level `exists` functions to decouple map users from its implementation.
|
|
|
84a089da
|
2018-12-01T08:50:36
|
|
maps: provide return value when deleting entries
Currently, the delete functions of maps do not provide a return value. Like
this, it is impossible to tell whether the entry has really been deleted or not.
Change the implementation to provide either a return value of zero if the entry
has been successfully deleted or `GIT_ENOTFOUND` if the key could not be found.
Convert callers to the `delete_at` functions to instead use this higher-level
interface.
|
|
|
8da93944
|
2018-12-01T10:52:44
|
|
idxmap: have `resize` functions return proper error code
The currently existing function `git_idxmap_resize` and
`git_idxmap_icase_resize` do not return any error codes at all due to their
previous implementation making use of a macro. Due to that, it is impossible to
see whether the resize operation might have failed due to an out-of-memory
situation.
Fix this by providing a proper error code. Adjust callers to make use of it.
|
|
|
661fc57b
|
2018-12-01T01:16:25
|
|
idxmap: introduce high-level setter for key/value pairs
Currently, one would use the function `git_idxmap_insert` to insert key/value
pairs into a map. This function has historically been a macro, which is why its
syntax is kind of weird: instead of returning an error code directly, it instead
has to be passed a pointer to where the return value shall be stored. This does
not match libgit2's common idiom of directly returning error codes.
Introduce a new function `git_idxmap_set`, which takes as parameters the map,
key and value and directly returns an error code. Convert all callers of
`git_idxmap_insert` to make use of it.
|
|
|
d00c24a9
|
2019-01-23T10:49:25
|
|
idxmap: introduce high-level getter for values
The current way of looking up an entry from a map is tightly coupled with the
map implementation, as one first has to look up the index of the key and then
retrieve the associated value by using the index. As a caller, you usually do
not care about any indices at all, though, so this is more complicated than
really necessary. Furthermore, it invites for errors to happen if the correct
error checking sequence is not being followed.
Introduce new high-level functions `git_idxmap_get` and `git_idxmap_icase_get`
that take a map and a key and return a pointer to the associated value if such a
key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can
trivially be converted.
|
|
|
b9d0b664
|
2018-12-17T09:10:53
|
|
offmap: introduce high-level setter for key/value pairs
Currently, there is only one caller that adds entries into an offset map, and
this caller first uses `git_offmap_put` to add a key and then set the value at
the returned index by using `git_offmap_set_value_at`. This is just too tighlty
coupled with implementation details of the map as it exposes the index of
inserted entries, which we really do not care about at all.
Introduce a new function `git_offmap_set`, which takes as parameters the map,
key and value and directly returns an error code. Convert the caller to make use
of it instead.
|
|
|
aa245623
|
2018-11-30T18:28:05
|
|
offmap: introduce high-level getter for values
The current way of looking up an entry from a map is tightly coupled with the
map implementation, as one first has to look up the index of the key and then
retrieve the associated value by using the index. As a caller, you usually do
not care about any indices at all, though, so this is more complicated than
really necessary. Furthermore, it invites for errors to happen if the correct
error checking sequence is not being followed.
Introduce a new high-level function `git_offmap_get` that takes a map and a key
and returns a pointer to the associated value if such a key exists. Otherwise,
a `NULL` pointer is returned. Adjust all callers that can trivially be
converted.
|