- 09 Nov, 2021 1 commit
-
-
Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
Edward Thomson committed
-
- 17 Oct, 2021 1 commit
-
-
libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson committed
-
- 09 Sep, 2021 1 commit
-
-
Make some syntax change to follow coding style.
punkymaniac committed
-
- 15 Feb, 2021 1 commit
-
-
Aaron Franke committed
-
- 27 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 25 Nov, 2020 1 commit
-
-
`git_buf_copy_cstr` is called with user-input, and wants to sanity-check that input. Allow it to return a value if the input was malformed in a way that we cannot cope.
Edward Thomson committed
-
- 25 Oct, 2020 4 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
Provide a function that can check reference name validity but can also signal when an error occurs. Use the name "name_is_valid", which is more suggestive of checking a given name, rather than "is_valid_name", which suggests that the function checks the validity of the current reference's name.
Edward Thomson committed -
Move `git_reference__is_valid_name` to `git_reference__name_is_valid`, which returns errors and sets an out boolean parameter.
Edward Thomson committed
-
- 18 Sep, 2020 1 commit
-
-
The `signature` variable in `git_reference_rename` isn't initialized and neither does `git_reference__log_signature` always do. So if the latter function fails, we'll call `git_signature_free` on this unininitialized variable. Fix the issue by initializing the pointer with `NULL`.
Patrick Steinhardt committed
-
- 12 Jul, 2020 5 commits
-
-
With the last user of `git_reference__read_head` gone, let's remove it as it's been reading references without consulting the refdb backends.
Patrick Steinhardt committed -
When renaming a reference, we need to iterate over every HEAD and potentially update it in case it is a symbolic reference pointing to the previous name of the renamed reference. Most importantly, this doesn't only include HEADs from the repo we're renaming the reference in, but we also need to iterate over HEADs from linked worktrees. In order to update the HEADs, we directly read them from the worktree's gitdir and thus assume that both repository and worktrees use the filesystem-based reference backend. But this breaks as soon as one got a repository with a different refdb and breaks our own abstractions. So let's instead update HEAD references via the refdb by first opening each worktree as a repository and then using the usual functions to read and update HEADs. This is a lot less efficient than the current code, but it's not like we can really help this: going via the refdb is mandatory.
Patrick Steinhardt committed -
The refs code currently has a second implementation that resolves references in order to find any final symbolic reference pointing to a nonexistent target branch. As we've just extended `git_refdb_resolve` to also return such references, let's use that one instead in order to reduce code duplication.
Patrick Steinhardt committed -
In some cases, resolving references requires us to also know about the final symbolic reference that's pointing to a nonexistent branch, e.g. in an empty repository where the main branch is yet unborn but HEAD already points to it. Right now, the resolving logic is thus split up into two, where one is the new refdb implementation and the second one is an ad-hoc implementation inside "refs.c". Let's extend `git_refdb_resolve` to also return such final dangling references pointing to nonexistent branches so we can deduplicate the resolving logic.
Patrick Steinhardt committed -
Resolving of symbolic references is currently implemented inside the "refs" layer. As a result, it's hard to call this function from low-level parts that only have a refdb available, but no repository, as the "refs" layer always operates on the repository-level. So let's move the function into the generic "refdb" implementation to lift this restriction.
Patrick Steinhardt committed
-
- 09 Jun, 2020 1 commit
-
-
We've accumulated quite some functions which are never used outside of their respective code unit, but which are lacking the `static` keyword. Add it to reduce their linkage scope and allow the compiler to optimize better.
Patrick Steinhardt committed
-
- 15 Jan, 2020 1 commit
-
-
This requires adding a new symbolic ref to the testrepo fixture. Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead. Adjust a few other tests as needed. Fixes #5357
Josh Bleecher Snyder committed
-
- 13 Dec, 2019 1 commit
-
-
As git_reference__name will reallocate storage to account for longer names (it's actually allocator-dependent), it will cause all existing pointers to the old object to become dangling, as they now point to freed memory. Fix the issue by renaming to a more descriptive name, and pass a pointer to the actual reference that can safely be invalidated if the realloc succeeds.
Etienne Samson committed
-
- 20 Jul, 2019 1 commit
-
-
Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
Patrick Steinhardt committed
-
- 18 Jul, 2019 1 commit
-
-
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
Patrick Steinhardt committed
-
- 15 Jun, 2019 1 commit
-
-
The only function that is named `issomething` (without underscore) was `git_oid_iszero`. Rename it to `git_oid_is_zero` for consistency with the rest of the library.
Edward Thomson committed
-
- 26 Apr, 2019 1 commit
-
-
In commit cd377f45c9 (refs: loosen restriction on wildcard "*" refspecs, 2015-07-22) in git.git, the restrictions on wildcard "*" refspecs has been loosened. While wildcards were previously only allowed if the component is a single "*", this was changed to also accept other patterns as part of the component. We never adapted to that change and still reject any wildcard patterns that aren't a single "*" only. Update our tests to reflect the upstream change and adjust our own code accordingly.
Patrick Steinhardt committed
-
- 14 Feb, 2019 1 commit
-
-
Right now, the function `git_repository_foreach_head` will always iterate over all HEADs of the main repository and its worktrees. In some cases, it might be required to skip either of those, though. Add a flag in preparation for the following commit that enables this behaviour.
Patrick Steinhardt committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 17 Jan, 2019 1 commit
-
-
Update internal usage to use the `git_reference` names for constants.
Edward Thomson committed
-
- 04 Jan, 2019 1 commit
-
-
CID 1382962
Etienne Samson committed
-
- 14 Dec, 2018 1 commit
-
-
We have no need to take a non-const reference. This does involve some other work to make sure we don't mix const and non-const variables, but by splitting what we want each variable to do we can also simplify the logic for when we do want to free a new reference we might have allocated.
Carlos Martín Nieto committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 19 Oct, 2018 1 commit
-
-
This moves the current merge analysis code into a more generic version that can work against any reference. Also change the tests to check returned analysis values exactly.
Etienne Samson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 10 Apr, 2018 1 commit
-
-
This fixes a segfault in git_reference_owner on references returned from git_reference__read_head and git_reference_dup ones.
Etienne Samson committed
-
- 06 Oct, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 03 Jul, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 08 Jun, 2017 1 commit
-
-
Patrick Steinhardt committed
-
- 01 May, 2017 1 commit
-
-
Be sure to clean up looked up references. Free buffers instead of merely clearing them. Use `git__free` instead of `free`.
Edward Thomson committed
-
- 05 Apr, 2017 2 commits
-
-
Whenever we rename a branch, we update the repository's symbolic HEAD reference if it currently points to the branch that is to be renamed. But with the introduction of worktrees, we also have to iterate over all HEADs of linked worktrees to adjust them. Do so.
Patrick Steinhardt committed -
Currently, we only provide functions to read references directly from a repository's reference store via e.g. `git_reference_lookup`. But in some cases, we may want to read files not connected to the current repository, e.g. when looking up HEAD of connected work trees. This commit implements `git_reference__read_head`, which will read out and allocate a reference at an arbitrary path.
Patrick Steinhardt committed
-
- 27 Feb, 2017 1 commit
-
-
This fixes issue #4094
Richard Ipsum committed
-
- 17 Feb, 2017 1 commit
-
-
Patrick Steinhardt committed
-