| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \ \
| | | | |
| | | | | |
patch_parse: fix parsing addition/deletion of file with space
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add a test that verifies that we are able to parse patches which add a
new file that has spaces in its path.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | |/ / / |
|
| |\ \ \ \
| |_|_|/
|/| | | |
Optimize string comparisons
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
Negation of subdir ignore causes other subdirs to be unignored
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |/ /
| | |
| | |
| | | |
When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored
|
| |\ \ \
| | | |
| | | | |
xdiff: fix typo
|
| | |/ / |
|
| |\ \ \
| | | |
| | | | |
docs: clarify relation of safe and forced checkout strategy
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | | |
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).
|
| |\ \ \
| | | |
| | | | |
[Doc] Update URL to git2-rs
|
| |/ / / |
|
| |\ \ \
| | | |
| | | | |
remote: Rename git_remote_completion_type to _t
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
For consistency with other "type" enums, rename
git_remote_completion_type to git_remote_completion_t.
|
| |\ \ \ \
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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_.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 1fe3fa5e59818c851d50efc6563db5f8a5d7ae9b.
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Have git_branch_lookup accept GIT_BRANCH_ALL
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Rename git_transfer_progress to git_indexer_progress
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Safely deprecate `git_push_transfer_progress`, forwarding it to the new
`git_push_transfer_progress_cb` name.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Safely deprecate `git_transfer_progress` and `git_transfer_progress_cb`
types, forwarding them to the new `git_indexer_progress` and
`git_indexer_progress_cb`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Update internal usage of `git_transfer_progress` to
`git_indexer_progreses`.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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`.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
High-level map APIs
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
