| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This should be a good place to eventually make use of `_fromstate` depending on
what we're trying to show in this example.
|
|
|
|
|
| |
We now have `_fromstate` and `_fromstate_on_head`, the latter of which updates
the current branch to point to the new commit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently git_commit_create() takes on creating a commit and updating a
reference. Provide a better interface by splitting up each of the
concerns into named functions for each.
git_commit_create() will only create the commit, it will not modify any
reference. git_commit_create_on() takes a reference name to update and
git_commit_create_on_head() is a convenience function to update HEAD.
|
|
|
|
|
|
| |
This variant of the commit creation function takes the reference to
update, the tree and the parents from the current branch, index and
merging state, allowing for simpler use of a common use-case.
|
|\
| |
| | |
online tests: update auth for bitbucket test
|
|/
|
|
|
| |
Update the settings to use a specific read-only token for accessing our
test repositories in Bitbucket.
|
|\
| |
| | |
Refactor `gitno_extract_url_parts`
|
| | |
|
| |
| |
| |
| |
| | |
RFC 3986 says that hostnames can be percent encoded. Percent decode
hostnames in our URLs.
|
| | |
|
| |
| |
| |
| |
| | |
Now that we can decode percent-encoded strings as part of `git_buf`s,
use that decoder in `gitno_extract_url_parts`.
|
| |
| |
| |
| |
| | |
Use `git_buf_decode_percent` so that we can avoid allocating a temporary
buffer.
|
| |
| |
| |
| |
| | |
Introduce a function to take a percent-encoded string (URI encoded,
described by RFC 1738) and decode it into a `git_buf`.
|
| | |
|
| | |
|
|/ |
|
|\
| |
| | |
online::clone: skip creds fallback test
|
|/
|
|
|
|
|
|
|
|
|
|
| |
At present, we have three online tests against bitbucket: one which
specifies the credentials in the payload, one which specifies the
correct credentials in the URL and a final one that specifies the
incorrect credentials in the URL. Bitbucket has begun responding to the
latter test with a 403, which causes us to fail.
Break these three tests into separate tests so that we can skip the
latter until this is resolved on Bitbucket's end or until we can change
the test to a different provider.
|
|\
| |
| | |
pathspec: improve git_pathspec_flag_t doc rendering
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By placing docs per enum value rather than in a large block,
the automated doc generation tool can make nicer docs,
as could other automated tools, such as
the mooted https://github.com/libgit2/git2go/issues/427.
The current rendering is somewhat ugly:
https://libgit2.github.com/libgit2/#HEAD/type/git_pathspec_flag_t
No textual changes, just reorganization.
|
|\ \
| | |
| | | |
Index parsing fixes
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When computing the complete path length from the encoded
prefix-compressed path, we end up just allocating the complete path
without ever checking what the encoded path length actually is. This can
easily lead to a denial of service by just encoding an unreasonable long
path name inside of the index. Git already enforces a maximum path
length of 4096 bytes. As we also have that enforcement ready in some
places, just make sure that the resulting path is smaller than
GIT_PATH_MAX.
Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The index format in version 4 has prefix-compressed entries, where every
index entry can compress its path by using a path prefix of the previous
entry. Since implmenting support for this index format version in commit
5625d86b9 (index: support index v4, 2016-05-17), though, we do not
correctly verify that the prefix length that we want to reuse is
actually smaller or equal to the amount of characters than the length of
the previous index entry's path. This can lead to a an integer underflow
and subsequently to an out-of-bounds read.
Fix this by verifying that the prefix is actually smaller than the
previous entry's path length.
Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The function `read_entry` does not conform to our usual coding style of
returning stuff via the out parameter and to use the return value for
reporting errors. Due to most of our code conforming to that pattern, it
has become quite natural for us to actually return `-1` in case there is
any error, which has also slipped in with commit 5625d86b9 (index:
support index v4, 2016-05-17). As the function returns an `size_t` only,
though, the return value is wrapped around, causing the caller of
`read_tree` to continue with an invalid index entry. Ultimately, this
can lead to a double-free.
Improve code and fix the bug by converting the function to return the
index entry size via an out parameter and only using the return value to
indicate errors.
Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
|
|\ \ \
| |/ /
|/| | |
config: specify how we match the regular expressions
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We do it the same as git does: case-sensitively on the normalized form of the
variable name.
While here also specify that we're case-sensitive on the values when handling
the values when setting or deleting multivars.
|
|\ \ \
| | | |
| | | | |
Integer overflow
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
deps: upgrade embedded zlib to version 1.2.11
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current version of zlib bundled with libgit2 is version 1.2.8. This
version has several CVEs assigned:
- CVE-2016-9843
- CVE-2016-9841
- CVE-2016-9842
- CVE-2016-9840
Upgrade the bundled version to the current release 1.2.11, which has
these vulnerabilities fixes.
|
|\ \ \
| | | |
| | | | |
CHANGELOG: mention the change to `git_odb_open_rstream`
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | | |
Worktree lock reason should be const
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
Cast less blindly between configuration objects
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of treating it as a no-op, treat it as a programming error and return
the same kind of error as if you called to set or delete variables on a
snapshot.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When we create an iterator we don't actually know that we have a live config
object and we must instead only rely on the header. We fixed it to use this in a
previous commit, but this makes it harder to misuse by converting to use the
header object in the typecast.
We also guard inside the `config_refresh` function against being given a
snapshot (although callers right now do check).
|
| | | |
| | | |
| | | |
| | | |
| | | | |
We use it in a few places where we might have a full object or a snapshot so
move it to where we can actually access it.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We pass this around and when creating a new iterator we need to read the
repository pointer.
Put it in a common place so we can reach it regardless of whether we got a full
object or a snapshot.
|
|\ \ \ \
| | | | |
| | | | | |
curl: initialize and cleanup global curl state
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Our curl-based streams make use of the easy curl interface. This
interface automatically initializes and de-initializes the global curl
state by calling out to `curl_global_init` and `curl_global_cleanup`.
Thus, all global state will be repeatedly re-initialized when creating
multiple curl streams in succession. Despite being inefficient, this is
not thread-safe due to `curl_global_init` being not thread-safe itself.
Thus a multi-threaded programing handling multiple curl streams at the
same time is inherently racy.
Fix the issue by globally initializing and cleaning up curl's state.
|
|\ \ \ \
| | | | |
| | | | | |
tree: initialize the id we use for testing submodule insertions
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of laving it uninitialized and relying on luck for it to be non-zero,
let's give it a dummy hash so we make valgrind happy (in this case the hash
comes from `sha1sum </dev/null`.
|
|\ \ \ \
| |/ / /
|/| | | |
win32: strncmp -> git__strncmp for win32 STDCALL
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The win32 C library is compiled cdecl, however when configured with
`STDCALL=ON`, our functions (and function pointers) will use the stdcall
calling convention. You cannot set a `__stdcall` function pointer to a
`__cdecl` function, so it's easier to just use our `git__strncmp`
instead of sorting that mess out.
|
|\ \ \
| | | |
| | | | |
Respect core.filemode in checkout
|