delta/libgit2.git/src/refs.c, branch threading-docs

git_error: use new names in internal APIs and usage

2019-01-22T22:30:35+00:00

Move to the `git_error` name in the internal API for error-related
functions.

references: use new names in internal usage

2019-01-17T10:32:29+00:00

Update internal usage to use the `git_reference` names for constants.

refs: assert that we're passed valid refs when renaming

2019-01-04T12:33:55+00:00

CID 1382962

refs: constify git_reference_peel

2018-12-14T13:44:27+00:00

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 names

2018-12-01T11:54:57+00:00

Use the new object_type enumeration names within the codebase.

merge: make analysis possible against a non-HEAD reference

2018-10-19T18:39:17+00:00

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`

2018-06-10T17:34:37+00:00

refs: preserve the owning refdb when duping reference

2018-04-10T21:45:00+00:00

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 tag

2017-10-06T10:44:00+00:00

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" first

2017-07-03T08:51:48+00:00

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.