summaryrefslogtreecommitdiff
path: root/src/refs.c
Commit message (Collapse)AuthorAgeFilesLines
* path: separate git-specific path functions from utilEdward Thomson2021-11-091-4/+4
| | | | | | 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).
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-171-28/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix coding style for pointerpunkymaniac2021-09-091-2/+2
| | | | Make some syntax change to follow coding style.
* Fix some typosAaron Franke2021-02-151-1/+1
|
* refs: use GIT_ASSERTEdward Thomson2020-11-271-30/+50
|
* buffer: git_buf_copy_cstr should return a valueEdward Thomson2020-11-251-1/+2
| | | | | | `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.
* refs: deprecate git_reference_is_valid_nameEdward Thomson2020-10-251-9/+15
|
* refs: use git_reference_name_is_validEdward Thomson2020-10-251-3/+4
|
* refs: introduce git_reference_name_is_validEdward Thomson2020-10-251-0/+7
| | | | | | | | 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.
* refs: error checking in internal name validationEdward Thomson2020-10-251-7/+20
| | | | | Move `git_reference__is_valid_name` to `git_reference__name_is_valid`, which returns errors and sets an out boolean parameter.
* refs: fix potential free of uninitialized variablePatrick Steinhardt2020-09-181-1/+1
| | | | | | | | | 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`.
* Merge pull request #5563 from pks-t/pks/worktree-headsEdward Thomson2020-08-031-99/+25
|\ | | | | Access HEAD via the refdb backends
| * refs: remove function to read HEAD directlyPatrick Steinhardt2020-07-121-34/+0
| | | | | | | | | | 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.
| * refs: update HEAD references via refdbPatrick Steinhardt2020-07-121-65/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | refs: replace reimplementation of reference resolverPatrick Steinhardt2020-07-121-49/+18
| | | | | | | | | | | | | | | | 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.
* | refdb: return resolved symbolic refs pointing to nonexistent refsPatrick Steinhardt2020-07-121-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | refs: move resolving of references into the refdbPatrick Steinhardt2020-07-121-40/+5
|/ | | | | | | | | 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.
* tree-wide: mark local functions as staticPatrick Steinhardt2020-06-091-2/+2
| | | | | | | 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.
* refs: refuse to delete HEADJosh Bleecher Snyder2020-01-151-0/+5
| | | | | | | 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
* refs: rename git_reference__set_name to git_reference__reallocEtienne Samson2019-12-131-5/+10
| | | | | | | | | | | 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.
* fileops: rename to "futils.h" to match function signaturesPatrick Steinhardt2019-07-201-1/+1
| | | | | | | | | 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.
* configuration: cvar -> configmapPatrick Steinhardt2019-07-181-1/+1
| | | | | `cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
* oid: `is_zero` instead of `iszero`Edward Thomson2019-06-161-2/+2
| | | | | | 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.
* refs: loosen restriction on wildcard "*" refspecsPatrick Steinhardt2019-04-261-13/+19
| | | | | | | | | | | | 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.
* branches: introduce flag to skip enumeration of certain HEADsPatrick Steinhardt2019-02-141-1/+1
| | | | | | | 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.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-25/+25
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* references: use new names in internal usageethomson/git_refEdward Thomson2019-01-171-38/+38
| | | | Update internal usage to use the `git_reference` names for constants.
* refs: assert that we're passed valid refs when renamingEtienne Samson2019-01-041-0/+2
| | | CID 1382962
* refs: constify git_reference_peelCarlos Martín Nieto2018-12-141-7/+8
| | | | | | | 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.
* object_type: use new enumeration namesethomson/index_fixesEdward Thomson2018-12-011-6/+6
| | | | Use the new object_type enumeration names within the codebase.
* merge: make analysis possible against a non-HEAD referenceEtienne Samson2018-10-191-0/+24
| | | | | | | 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.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-6/+6
|
* refs: preserve the owning refdb when duping referenceEtienne Samson2018-04-101-0/+3
| | | This fixes a segfault in git_reference_owner on references returned from git_reference__read_head and git_reference_dup ones.
* refs: do not use peeled OID if peeling to a tagPatrick Steinhardt2017-10-061-1/+7
| | | | | | | | | | | | | | | | | | | | | | 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.
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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.
* refs: properly report errors from `update_wt_heads`Patrick Steinhardt2017-06-081-6/+16
|
* worktrees: cleanup some memory leaksEdward Thomson2017-05-011-2/+2
| | | | | Be sure to clean up looked up references. Free buffers instead of merely clearing them. Use `git__free` instead of `free`.
* refs: update worktree HEADs when renaming branchesPatrick Steinhardt2017-04-051-8/+45
| | | | | | | 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.
* refs: implement function to read references from filePatrick Steinhardt2017-04-051-0/+34
| | | | | | | | | 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.
* Fix: make reflog include "(merge)" for merge commitsRichard Ipsum2017-02-271-1/+13
| | | | This fixes issue #4094
* strmap: remove GIT__USE_STRMAP macroPatrick Steinhardt2017-02-171-2/+0
|
* Merge branch 'pr/3912'Edward Thomson2017-01-211-6/+23
|\
| * symbolic ref target validation: fixupsEdward Thomson2017-01-211-29/+9
| | | | | | | | Fixups requested in #3912.
| * Make symbolic ref target validation optionalRichard Ipsum2016-08-271-4/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce GIT_OPT_ENABLE_SYMBOLIC_REF_TARGET_VALIDATION option. Setting this option to 0 allows validation of a symbolic ref's target to be bypassed. This option is enabled by default. This mechanism is added primarily to address a discrepancy between git behaviour and libgit2 behaviour, whereby the former allows the symbolic ref target to carry an arbitrary string and the latter does not, so: $ git symbolic-ref refs/heads/foo bar $ cat .git/refs/heads/foo ref: bar where as attempting the same via libgit2 raises an error: The given reference name 'bar' is not valid this mechanism also allows those that might want to make use of git's more lenient treatment of symbolic ref targets to do so.
* | giterr_set: consistent error messagesEdward Thomson2016-12-291-11/+11
|/ | | | | | | | Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
* Allow creating copies of `git_reference` objects.Arthur Schreiber2016-04-221-1/+13
|
* refs: provide a more general error message for dwimcmn/dwim-general-messageCarlos Martín Nieto2016-04-111-0/+3
| | | | | | | If we cannot dwim the input, set the error message to be explicit about that. Otherwise we leave the error for the last failed lookup, which can be rather unexpected as it mentions a remote when the user thought they were trying to look up a branch.
* refs: honor strict object creationEdward Thomson2016-02-281-7/+1
|
* Fixed Xcode 6.1 build warningsPierre-Olivier Latour2015-06-151-1/+1
|
* squash some leaksEdward Thomson2015-03-241-5/+3
|
View Lorry Controller Status