- 10 Apr, 2023 1 commit
-
-
Edward Thomson committed
-
- 15 Jun, 2022 1 commit
-
-
In preparation for SHA256 support, `GIT_OID_RAWSZ` and `GIT_OID_HEXSZ` need to indicate that they're the size of _SHA1_ OIDs.
Edward Thomson committed
-
- 23 Feb, 2022 1 commit
-
-
Edward Thomson committed
-
- 25 Nov, 2020 1 commit
-
-
Edward Thomson 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 some missed types that were continuing to use the old `GIT_OBJ` names.
Edward Thomson committed
-
- 14 Dec, 2018 1 commit
-
-
We want to allow the creation of annotated commits out of annotated tags and for that we have to peel the reference all the way to the commit instead of stopping at the first id it provides.
Carlos Martín Nieto committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 07 Jul, 2018 1 commit
-
-
As git_annotated_commit seems to behave like cgit's refish, it's quite helpful to abstract away "targets" via git_annotated_commit_from_id/from_ref. As the former is accessible via git_annotated_commit_id, make the latter also available to users.
Etienne Samson 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
-
- 26 Apr, 2016 1 commit
-
-
Differentiate between the ref_name used to create an annotated_commit (that can subsequently be used to look up the reference) and the description that we resolved this with (which _cannot_ be looked up). The description is used for things like reflogs (and may be a ref name, and ID something that we revparsed to get here), while the ref name must actually be a reference name, and is used for things like rebase to return to the initial branch.
Edward Thomson committed
-
- 25 Nov, 2015 3 commits
-
-
Use annotated commits to act as our virtual bases, instead of regular commits, to avoid polluting the odb with virtual base commits and trees. Instead, build an annotated commit with an index and pointers to the commits that it was merged from.
Edward Thomson committed -
Edward Thomson committed
-
When there are more than two common ancestors, continue merging the virtual base with the additional common ancestors, effectively octopus merging a new virtual base.
Edward Thomson committed
-
- 16 Mar, 2015 1 commit
-
-
This extra constructor will be useful for the annotated versions of ref-modifying functions, as it allows us to create a commit with the extended sha syntax which was used to retrieve it.
Carlos Martín Nieto committed
-
- 27 Oct, 2014 1 commit
-
-
Rename git_merge_head to git_annotated_commit, as it becomes used in more operations than just merge.
Edward Thomson committed
-