src/annotated_commit.c


Log

Author Commit Date CI Message
Carlos Martín Nieto 6ea9381b 2018-12-14T14:43:09 annotated_commit: peel to commit instead of assuming we have one 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.
Edward Thomson 168fe39b 2018-11-28T14:26:57 object_type: use new enumeration names Use the new object_type enumeration names within the codebase.
Etienne Samson 698b4463 2018-06-23T13:06:10 annotated_commit: make the refname accessible 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.
Patrick Steinhardt 0c7f49dd 2017-06-30T13:39:01 Make sure to always include "common.h" first 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.
Edward Thomson d5592378 2016-04-26T11:39:53 annotated_commit: provide refs and description 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 76ade3a0 2015-11-10T21:21:26 merge: use annotated commits for recursion 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 7730fe8e 2015-11-09T13:01:48 merge: merge annotated commits instead of regular commits
Edward Thomson 3f2bb387 2015-10-28T11:00:55 merge: octopus merge common ancestors when >2 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.
Carlos Martín Nieto 62dd4d71 2015-03-07T00:06:02 annotated_commit: provide a constructor from a revspec 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.
Edward Thomson 18b00406 2014-10-03T19:02:29 s/git_merge_head/git_annotated_commit Rename git_merge_head to git_annotated_commit, as it becomes used in more operations than just merge.