LibGit2
The LibGit2 module provides bindings to libgit2, a portable C library that implements core functionality for the Git version control system. These bindings are currently used to power Julia’s package manager. It is expected that this module will eventually be moved into a separate package.
Functionality
Some of this documentation assumes some prior knowledge of the libgit2 API. For more information on some of the objects and methods referenced here, consult the upstream libgit2 API reference.
LibGit2.Buffer — Type
1. LibGit2.Buffer
A data buffer for exporting data from libgit2. Matches the git_buf struct.
When fetching data from LibGit2, a typical usage would look like:
1. buf_ref = Ref(Buffer())
2. @check ccall(..., (Ptr{Buffer},), buf_ref)
3. # operation on buf_ref
4. free(buf_ref)
In particular, note that LibGit2.free should be called afterward on the Ref object.
LibGit2.CheckoutOptions — Type
1. LibGit2.CheckoutOptions
Matches the git_checkout_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.checkout_strategy: determine how to handle conflicts and whether to force the checkout/recreate missing files.disable_filters: if nonzero, do not apply filters like CLRF (to convert file newlines between UNIX and DOS).dir_mode: read/write/access mode for any directories involved in the checkout. Default is0755.file_mode: read/write/access mode for any files involved in the checkout. Default is0755or0644, depending on the blob.file_open_flags: bitflags used to open any files during the checkout.notify_flags: Flags for what sort of conflicts the user should be notified about.notify_cb: An optional callback function to notify the user if a checkout conflict occurs. If this function returns a non-zero value, the checkout will be cancelled.notify_payload: Payload for the notify callback function.progress_cb: An optional callback function to display checkout progress.progress_payload: Payload for the progress callback.paths: If not empty, describes which paths to search during the checkout. If empty, the checkout will occur over all files in the repository.baseline: Expected content of theworkdir, captured in a (pointer to a)GitTree. Defaults to the state of the tree at HEAD.baseline_index: Expected content of theworkdir, captured in a (pointer to a)GitIndex. Defaults to the state of the index at HEAD.target_directory: If not empty, checkout to this directory instead of theworkdir.ancestor_label: In case of conflicts, the name of the common ancestor side.our_label: In case of conflicts, the name of “our” side.their_label: In case of conflicts, the name of “their” side.perfdata_cb: An optional callback function to display performance data.perfdata_payload: Payload for the performance callback.
LibGit2.CloneOptions — Type
1. LibGit2.CloneOptions
Matches the git_clone_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.checkout_opts: The options for performing the checkout of the remote as part of the clone.fetch_opts: The options for performing the pre-checkout fetch of the remote as part of the clone.bare: If0, clone the full remote repository. If non-zero, perform a bare clone, in which there is no local copy of the source files in the repository and thegitdirandworkdirare the same.localclone: Flag whether to clone a local object database or do a fetch. The default is to let git decide. It will not use the git-aware transport for a local clone, but will use it for URLs which begin withfile://.checkout_branch: The name of the branch to checkout. If an empty string, the default branch of the remote will be checked out.repository_cb: An optional callback which will be used to create the new repository into which the clone is made.repository_cb_payload: The payload for the repository callback.remote_cb: An optional callback used to create theGitRemotebefore making the clone from it.remote_cb_payload: The payload for the remote callback.
LibGit2.DescribeOptions — Type
1. LibGit2.DescribeOptions
Matches the git_describe_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.max_candidates_tags: consider this many most recent tags inrefs/tagsto describe a commit. Defaults to 10 (so that the 10 most recent tags would be examined to see if they describe a commit).describe_strategy: whether to consider all entries inrefs/tags(equivalent togit-describe --tags) or all entries inrefs/(equivalent togit-describe --all). The default is to only show annotated tags. IfConsts.DESCRIBE_TAGSis passed, all tags, annotated or not, will be considered. IfConsts.DESCRIBE_ALLis passed, any ref inrefs/will be considered.pattern: only consider tags which matchpattern. Supports glob expansion.only_follow_first_parent: when finding the distance from a matching reference to the described object, only consider the distance from the first parent.show_commit_oid_as_fallback: if no matching reference can be found which describes a commit, show the commit’sGitHashinstead of throwing an error (the default behavior).
LibGit2.DescribeFormatOptions — Type
1. LibGit2.DescribeFormatOptions
Matches the git_describe_format_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.abbreviated_size: lower bound on the size of the abbreviatedGitHashto use, defaulting to7.always_use_long_format: set to1to use the long format for strings even if a short format can be used.dirty_suffix: if set, this will be appended to the end of the description string if theworkdiris dirty.
LibGit2.DiffDelta — Type
1. LibGit2.DiffDelta
Description of changes to one entry. Matches the git_diff_delta struct.
The fields represent:
status: One ofConsts.DELTA_STATUS, indicating whether the file has been added/modified/deleted.flags: Flags for the delta and the objects on each side. Determines whether to treat the file(s) as binary/text, whether they exist on each side of the diff, and whether the object ids are known to be correct.similarity: Used to indicate if a file has been renamed or copied.nfiles: The number of files in the delta (for instance, if the delta was run on a submodule commit id, it may contain more than one file).old_file: ADiffFilecontaining information about the file(s) before the changes.new_file: ADiffFilecontaining information about the file(s) after the changes.
LibGit2.DiffFile — Type
1. LibGit2.DiffFile
Description of one side of a delta. Matches the git_diff_file struct.
The fields represent:
id: theGitHashof the item in the diff. If the item is empty on this side of the diff (for instance, if the diff is of the removal of a file), this will beGitHash(0).path: aNULLterminated path to the item relative to the working directory of the repository.size: the size of the item in bytes.flags: a combination of thegit_diff_flag_tflags. Theith bit of this integer sets theith flag.mode: thestatmode for the item.id_abbrev: only present in LibGit2 versions newer than or equal to0.25.0. The length of theidfield when converted usingstring. Usually equal toOID_HEXSZ(40).
LibGit2.DiffOptionsStruct — Type
1. LibGit2.DiffOptionsStruct
Matches the git_diff_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.flags: flags controlling which files will appear in the diff. Defaults toDIFF_NORMAL.ignore_submodules: whether to look at files in submodules or not. Defaults toSUBMODULE_IGNORE_UNSPECIFIED, which means the submodule’s configuration will control whether it appears in the diff or not.pathspec: path to files to include in the diff. Default is to use all files in the repository.notify_cb: optional callback which will notify the user of changes to the diff as file deltas are added to it.progress_cb: optional callback which will display diff progress. Only relevant on libgit2 versions at least as new as 0.24.0.payload: the payload to pass tonotify_cbandprogress_cb.context_lines: the number of unchanged lines used to define the edges of a hunk. This is also the number of lines which will be shown before/after a hunk to provide context. Default is 3.interhunk_lines: the maximum number of unchanged lines between two separate hunks allowed before the hunks will be combined. Default is 0.id_abbrev: sets the length of the abbreviatedGitHashto print. Default is7.max_size: the maximum file size of a blob. Above this size, it will be treated as a binary blob. The default is 512 MB.old_prefix: the virtual file directory in which to place old files on one side of the diff. Default is"a".new_prefix: the virtual file directory in which to place new files on one side of the diff. Default is"b".
LibGit2.FetchHead — Type
1. LibGit2.FetchHead
Contains the information about HEAD during a fetch, including the name and URL of the branch fetched from, the oid of the HEAD, and whether the fetched HEAD has been merged locally.
The fields represent:
name: The name in the local reference database of the fetch head, for example,"refs/heads/master".url: The URL of the fetch head.oid: TheGitHashof the tip of the fetch head.ismerge: Boolean flag indicating whether the changes at the remote have been merged into the local copy yet or not. Iftrue, the local copy is up to date with the remote fetch head.
LibGit2.FetchOptions — Type
1. LibGit2.FetchOptions
Matches the git_fetch_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.callbacks: remote callbacks to use during the fetch.prune: whether to perform a prune after the fetch or not. The default is to use the setting from theGitConfig.update_fetchhead: whether to update theFetchHeadafter the fetch. The default is to perform the update, which is the normal git behavior.download_tags: whether to download tags present at the remote or not. The default is to request the tags for objects which are being downloaded anyway from the server.proxy_opts: options for connecting to the remote through a proxy. SeeProxyOptions. Only present on libgit2 versions newer than or equal to 0.25.0.custom_headers: any extra headers needed for the fetch. Only present on libgit2 versions newer than or equal to 0.24.0.
LibGit2.GitAnnotated — Type
1. GitAnnotated(repo::GitRepo, commit_id::GitHash)
2. GitAnnotated(repo::GitRepo, ref::GitReference)
3. GitAnnotated(repo::GitRepo, fh::FetchHead)
4. GitAnnotated(repo::GitRepo, committish::AbstractString)
An annotated git commit carries with it information about how it was looked up and why, so that rebase or merge operations have more information about the context of the commit. Conflict files contain information about the source/target branches in the merge which are conflicting, for instance. An annotated commit can refer to the tip of a remote branch, for instance when a FetchHead is passed, or to a branch head described using GitReference.
LibGit2.GitBlame — Type
1. GitBlame(repo::GitRepo, path::AbstractString; options::BlameOptions=BlameOptions())
Construct a GitBlame object for the file at path, using change information gleaned from the history of repo. The GitBlame object records who changed which chunks of the file when, and how. options controls how to separate the contents of the file and which commits to probe - see BlameOptions for more information.
LibGit2.GitBlob — Type
1. GitBlob(repo::GitRepo, hash::AbstractGitHash)
2. GitBlob(repo::GitRepo, spec::AbstractString)
Return a GitBlob object from repo specified by hash/spec.
hashis a full (GitHash) or partial (GitShortHash) hash.specis a textual specification: see the git docs for a full list.
LibGit2.GitCommit — Type
1. GitCommit(repo::GitRepo, hash::AbstractGitHash)
2. GitCommit(repo::GitRepo, spec::AbstractString)
Return a GitCommit object from repo specified by hash/spec.
hashis a full (GitHash) or partial (GitShortHash) hash.specis a textual specification: see the git docs for a full list.
LibGit2.GitHash — Type
1. GitHash
A git object identifier, based on the sha-1 hash. It is a 20 byte string (40 hex digits) used to identify a GitObject in a repository.
LibGit2.GitObject — Type
1. GitObject(repo::GitRepo, hash::AbstractGitHash)
2. GitObject(repo::GitRepo, spec::AbstractString)
Return the specified object (GitCommit, GitBlob, GitTree or GitTag) from repo specified by hash/spec.
hashis a full (GitHash) or partial (GitShortHash) hash.specis a textual specification: see the git docs for a full list.
LibGit2.GitRemote — Type
1. GitRemote(repo::GitRepo, rmt_name::AbstractString, rmt_url::AbstractString) -> GitRemote
Look up a remote git repository using its name and URL. Uses the default fetch refspec.
Examples
1. repo = LibGit2.init(repo_path)
2. remote = LibGit2.GitRemote(repo, "upstream", repo_url)
1. GitRemote(repo::GitRepo, rmt_name::AbstractString, rmt_url::AbstractString, fetch_spec::AbstractString) -> GitRemote
Look up a remote git repository using the repository’s name and URL, as well as specifications for how to fetch from the remote (e.g. which remote branch to fetch from).
Examples
1. repo = LibGit2.init(repo_path)
2. refspec = "+refs/heads/mybranch:refs/remotes/origin/mybranch"
3. remote = LibGit2.GitRemote(repo, "upstream", repo_url, refspec)
LibGit2.GitRemoteAnon — Function
1. GitRemoteAnon(repo::GitRepo, url::AbstractString) -> GitRemote
Look up a remote git repository using only its URL, not its name.
Examples
1. repo = LibGit2.init(repo_path)
2. remote = LibGit2.GitRemoteAnon(repo, repo_url)
LibGit2.GitRepo — Type
1. LibGit2.GitRepo(path::AbstractString)
Open a git repository at path.
LibGit2.GitRepoExt — Function
1. LibGit2.GitRepoExt(path::AbstractString, flags::Cuint = Cuint(Consts.REPOSITORY_OPEN_DEFAULT))
Open a git repository at path with extended controls (for instance, if the current user must be a member of a special access group to read path).
LibGit2.GitRevWalker — Type
1. GitRevWalker(repo::GitRepo)
A GitRevWalker walks through the revisions (i.e. commits) of a git repository repo. It is a collection of the commits in the repository, and supports iteration and calls to map and count (for instance, count could be used to determine what percentage of commits in a repository were made by a certain author).
1. cnt = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
2. count((oid,repo)->(oid == commit_oid1), walker, oid=commit_oid1, by=LibGit2.Consts.SORT_TIME)
3. end
Here, count finds the number of commits along the walk with a certain GitHash. Since the GitHash is unique to a commit, cnt will be 1.
LibGit2.GitShortHash — Type
1. GitShortHash(hash::GitHash, len::Integer)
A shortened git object identifier, which can be used to identify a git object when it is unique, consisting of the initial len hexadecimal digits of hash (the remaining digits are ignored).
LibGit2.GitSignature — Type
1. LibGit2.GitSignature
This is a Julia wrapper around a pointer to a git_signature object.
LibGit2.GitStatus — Type
1. LibGit2.GitStatus(repo::GitRepo; status_opts=StatusOptions())
Collect information about the status of each file in the git repository repo (e.g. is the file modified, staged, etc.). status_opts can be used to set various options, for instance whether or not to look at untracked files or whether to include submodules or not. See StatusOptions for more information.
LibGit2.GitTag — Type
1. GitTag(repo::GitRepo, hash::AbstractGitHash)
2. GitTag(repo::GitRepo, spec::AbstractString)
Return a GitTag object from repo specified by hash/spec.
hashis a full (GitHash) or partial (GitShortHash) hash.specis a textual specification: see the git docs for a full list.
LibGit2.GitTree — Type
1. GitTree(repo::GitRepo, hash::AbstractGitHash)
2. GitTree(repo::GitRepo, spec::AbstractString)
Return a GitTree object from repo specified by hash/spec.
hashis a full (GitHash) or partial (GitShortHash) hash.specis a textual specification: see the git docs for a full list.
LibGit2.IndexEntry — Type
1. LibGit2.IndexEntry
In-memory representation of a file entry in the index. Matches the git_index_entry struct.
LibGit2.IndexTime — Type
1. LibGit2.IndexTime
Matches the git_index_time struct.
LibGit2.BlameOptions — Type
1. LibGit2.BlameOptions
Matches the git_blame_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.flags: one ofConsts.BLAME_NORMALorConsts.BLAME_FIRST_PARENT(the other blame flags are not yet implemented by libgit2).min_match_characters: the minimum number of alphanumeric characters which much change in a commit in order for the change to be associated with that commit. The default is 20. Only takes effect if one of theConsts.BLAME_*_COPIESflags are used, which libgit2 does not implement yet.newest_commit: theGitHashof the newest commit from which to look at changes.oldest_commit: theGitHashof the oldest commit from which to look at changes.min_line: the first line of the file from which to starting blaming. The default is1.max_line: the last line of the file to which to blame. The default is0, meaning the last line of the file.
LibGit2.MergeOptions — Type
1. LibGit2.MergeOptions
Matches the git_merge_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.flags: anenumfor flags describing merge behavior. Defined ingit_merge_flag_t. The corresponding Julia enum isGIT_MERGEand has values:MERGE_FIND_RENAMES: detect if a file has been renamed between the common ancestor and the “ours” or “theirs” side of the merge. Allows merges where a file has been renamed.MERGE_FAIL_ON_CONFLICT: exit immediately if a conflict is found rather than trying to resolve it.MERGE_SKIP_REUC: do not write the REUC extension on the index resulting from the merge.MERGE_NO_RECURSIVE: if the commits being merged have multiple merge bases, use the first one, rather than trying to recursively merge the bases.rename_threshold: how similar two files must to consider one a rename of the other. This is an integer that sets the percentage similarity. The default is 50.target_limit: the maximum number of files to compare with to look for renames. The default is 200.metric: optional custom function to use to determine the similarity between two files for rename detection.recursion_limit: the upper limit on the number of merges of common ancestors to perform to try to build a new virtual merge base for the merge. The default is no limit. This field is only present on libgit2 versions newer than 0.24.0.default_driver: the merge driver to use if both sides have changed. This field is only present on libgit2 versions newer than 0.25.0.file_favor: how to handle conflicting file contents for thetextdriver.MERGE_FILE_FAVOR_NORMAL: if both sides of the merge have changes to a section, make a note of the conflict in the index whichgit checkoutwill use to create a merge file, which the user can then reference to resolve the conflicts. This is the default.MERGE_FILE_FAVOR_OURS: if both sides of the merge have changes to a section, use the version in the “ours” side of the merge in the index.MERGE_FILE_FAVOR_THEIRS: if both sides of the merge have changes to a section, use the version in the “theirs” side of the merge in the index.MERGE_FILE_FAVOR_UNION: if both sides of the merge have changes to a section, include each unique line from both sides in the file which is put into the index.file_flags: guidelines for merging files.
LibGit2.ProxyOptions — Type
1. LibGit2.ProxyOptions
Options for connecting through a proxy.
Matches the git_proxy_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.proxytype: anenumfor the type of proxy to use. Defined ingit_proxy_t. The corresponding Julia enum isGIT_PROXYand has values:PROXY_NONE: do not attempt the connection through a proxy.PROXY_AUTO: attempt to figure out the proxy configuration from the git configuration.PROXY_SPECIFIED: connect using the URL given in theurlfield of this struct.Default is to auto-detect the proxy type.url: the URL of the proxy.credential_cb: a pointer to a callback function which will be called if the remote requires authentication to connect.certificate_cb: a pointer to a callback function which will be called if certificate verification fails. This lets the user decide whether or not to keep connecting. If the function returns1, connecting will be allowed. If it returns0, the connection will not be allowed. A negative value can be used to return errors.payload: the payload to be provided to the two callback functions.
Examples
1. julia> fo = LibGit2.FetchOptions(
2. proxy_opts = LibGit2.ProxyOptions(url = Cstring("https://my_proxy_url.com")))
4. julia> fetch(remote, "master", options=fo)
LibGit2.PushOptions — Type
1. LibGit2.PushOptions
Matches the git_push_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.parallelism: if a pack file must be created, this variable sets the number of worker threads which will be spawned by the packbuilder. If0, the packbuilder will auto-set the number of threads to use. The default is1.callbacks: the callbacks (e.g. for authentication with the remote) to use for the push.proxy_opts: only relevant if the LibGit2 version is greater than or equal to0.25.0. Sets options for using a proxy to communicate with a remote. SeeProxyOptionsfor more information.custom_headers: only relevant if the LibGit2 version is greater than or equal to0.24.0. Extra headers needed for the push operation.
LibGit2.RebaseOperation — Type
1. LibGit2.RebaseOperation
Describes a single instruction/operation to be performed during the rebase. Matches the git_rebase_operation struct.
The fields represent:
optype: the type of rebase operation currently being performed. The options are:REBASE_OPERATION_PICK: cherry-pick the commit in question.REBASE_OPERATION_REWORD: cherry-pick the commit in question, but rewrite its message using the prompt.REBASE_OPERATION_EDIT: cherry-pick the commit in question, but allow the user to edit the commit’s contents and its message.REBASE_OPERATION_SQUASH: squash the commit in question into the previous commit. The commit messages of the two commits will be merged.REBASE_OPERATION_FIXUP: squash the commit in question into the previous commit. Only the commit message of the previous commit will be used.REBASE_OPERATION_EXEC: do not cherry-pick a commit. Run a command and continue if the command exits successfully.id: theGitHashof the commit being worked on during this rebase step.exec: in caseREBASE_OPERATION_EXECis used, the command to run during this step (for instance, running the test suite after each commit).
LibGit2.RebaseOptions — Type
1. LibGit2.RebaseOptions
Matches the git_rebase_options struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.quiet: inform other git clients helping with/working on the rebase that the rebase should be done “quietly”. Used for interoperability. The default is1.inmemory: start an in-memory rebase. Callers working on the rebase can go through its steps and commit any changes, but cannot rewind HEAD or update the repository. Theworkdirwill not be modified. Only present on libgit2 versions newer than or equal to 0.24.0.rewrite_notes_ref: name of the reference to notes to use to rewrite the commit notes as the rebase is finished.merge_opts: merge options controlling how the trees will be merged at each rebase step. Only present on libgit2 versions newer than or equal to 0.24.0.checkout_opts: checkout options for writing files when initializing the rebase, stepping through it, and aborting it. SeeCheckoutOptionsfor more information.
LibGit2.RemoteCallbacks — Type
1. LibGit2.RemoteCallbacks
Callback settings. Matches the git_remote_callbacks struct.
LibGit2.SignatureStruct — Type
1. LibGit2.SignatureStruct
An action signature (e.g. for committers, taggers, etc). Matches the git_signature struct.
The fields represent:
name: The full name of the committer or author of the commit.email: The email at which the committer/author can be contacted.when: aTimeStructindicating when the commit was authored/committed into the repository.
LibGit2.StatusEntry — Type
1. LibGit2.StatusEntry
Providing the differences between the file as it exists in HEAD and the index, and providing the differences between the index and the working directory. Matches the git_status_entry struct.
The fields represent:
status: contains the status flags for the file, indicating if it is current, or has been changed in some way in the index or work tree.head_to_index: a pointer to aDiffDeltawhich encapsulates the difference(s) between the file as it exists in HEAD and in the index.index_to_workdir: a pointer to aDiffDeltawhich encapsulates the difference(s) between the file as it exists in the index and in theworkdir.
LibGit2.StatusOptions — Type
1. LibGit2.StatusOptions
Options to control how git_status_foreach_ext() will issue callbacks. Matches the git_status_opt_t struct.
The fields represent:
version: version of the struct in use, in case this changes later. For now, always1.show: a flag for which files to examine and in which order. The default isConsts.STATUS_SHOW_INDEX_AND_WORKDIR.flags: flags for controlling any callbacks used in a status call.pathspec: an array of paths to use for path-matching. The behavior of the path-matching will vary depending on the values ofshowandflags.- The
baselineis the tree to be used for comparison to the working directory and index; defaults to HEAD.
LibGit2.StrArrayStruct — Type
1. LibGit2.StrArrayStruct
A LibGit2 representation of an array of strings. Matches the git_strarray struct.
When fetching data from LibGit2, a typical usage would look like:
1. sa_ref = Ref(StrArrayStruct())
2. @check ccall(..., (Ptr{StrArrayStruct},), sa_ref)
3. res = convert(Vector{String}, sa_ref[])
4. free(sa_ref)
In particular, note that LibGit2.free should be called afterward on the Ref object.
Conversely, when passing a vector of strings to LibGit2, it is generally simplest to rely on implicit conversion:
1. strs = String[...]
2. @check ccall(..., (Ptr{StrArrayStruct},), strs)
Note that no call to free is required as the data is allocated by Julia.
LibGit2.TimeStruct — Type
1. LibGit2.TimeStruct
Time in a signature. Matches the git_time struct.
LibGit2.add! — Function
1. add!(repo::GitRepo, files::AbstractString...; flags::Cuint = Consts.INDEX_ADD_DEFAULT)
2. add!(idx::GitIndex, files::AbstractString...; flags::Cuint = Consts.INDEX_ADD_DEFAULT)
Add all the files with paths specified by files to the index idx (or the index of the repo). If the file already exists, the index entry will be updated. If the file does not exist already, it will be newly added into the index. files may contain glob patterns which will be expanded and any matching files will be added (unless INDEX_ADD_DISABLE_PATHSPEC_MATCH is set, see below). If a file has been ignored (in .gitignore or in the config), it will not be added, unless it is already being tracked in the index, in which case it will be updated. The keyword argument flags is a set of bit-flags which control the behavior with respect to ignored files:
Consts.INDEX_ADD_DEFAULT- default, described above.Consts.INDEX_ADD_FORCE- disregard the existing ignore rules and force addition of the file to the index even if it is already ignored.Consts.INDEX_ADD_CHECK_PATHSPEC- cannot be used at the same time asINDEX_ADD_FORCE. Check that each file infileswhich exists on disk is not in the ignore list. If one of the files is ignored, the function will returnEINVALIDSPEC.Consts.INDEX_ADD_DISABLE_PATHSPEC_MATCH- turn off glob matching, and only add files to the index which exactly match the paths specified infiles.
LibGit2.add_fetch! — Function
1. add_fetch!(repo::GitRepo, rmt::GitRemote, fetch_spec::String)
Add a fetch refspec for the specified rmt. This refspec will contain information about which branch(es) to fetch from.
Examples
1. julia> LibGit2.add_fetch!(repo, remote, "upstream");
3. julia> LibGit2.fetch_refspecs(remote)
4. String["+refs/heads/*:refs/remotes/upstream/*"]
LibGit2.add_push! — Function
1. add_push!(repo::GitRepo, rmt::GitRemote, push_spec::String)
Add a push refspec for the specified rmt. This refspec will contain information about which branch(es) to push to.
Examples
1. julia> LibGit2.add_push!(repo, remote, "refs/heads/master");
3. julia> remote = LibGit2.get(LibGit2.GitRemote, repo, branch);
5. julia> LibGit2.push_refspecs(remote)
6. String["refs/heads/master"]
Note
You may need to close and reopen the GitRemote in question after updating its push refspecs in order for the change to take effect and for calls to push to work.
LibGit2.addblob! — Function
1. LibGit2.addblob!(repo::GitRepo, path::AbstractString)
Read the file at path and adds it to the object database of repo as a loose blob. Return the GitHash of the resulting blob.
Examples
1. hash_str = string(commit_oid)
2. blob_file = joinpath(repo_path, ".git", "objects", hash_str[1:2], hash_str[3:end])
3. id = LibGit2.addblob!(repo, blob_file)
LibGit2.author — Function
1. author(c::GitCommit)
Return the Signature of the author of the commit c. The author is the person who made changes to the relevant file(s). See also committer.
LibGit2.authors — Function
1. authors(repo::GitRepo) -> Vector{Signature}
Return all authors of commits to the repo repository.
Examples
1. repo = LibGit2.GitRepo(repo_path)
2. repo_file = open(joinpath(repo_path, test_file), "a")
4. println(repo_file, commit_msg)
5. flush(repo_file)
6. LibGit2.add!(repo, test_file)
7. sig = LibGit2.Signature("TEST", "TEST@TEST.COM", round(time(), 0), 0)
8. commit_oid1 = LibGit2.commit(repo, "commit1"; author=sig, committer=sig)
9. println(repo_file, randstring(10))
10. flush(repo_file)
11. LibGit2.add!(repo, test_file)
12. commit_oid2 = LibGit2.commit(repo, "commit2"; author=sig, committer=sig)
14. # will be a Vector of [sig, sig]
15. auths = LibGit2.authors(repo)
LibGit2.branch — Function
1. branch(repo::GitRepo)
Equivalent to git branch. Create a new branch from the current HEAD.
LibGit2.branch! — Function
1. branch!(repo::GitRepo, branch_name::AbstractString, commit::AbstractString=""; kwargs...)
Checkout a new git branch in the repo repository. commit is the GitHash, in string form, which will be the start of the new branch. If commit is an empty string, the current HEAD will be used.
The keyword arguments are:
track::AbstractString="": the name of the remote branch this new branch should track, if any. If empty (the default), no remote branch will be tracked.force::Bool=false: iftrue, branch creation will be forced.set_head::Bool=true: iftrue, after the branch creation finishes the branch head will be set as the HEAD ofrepo.
Equivalent to git checkout [-b|-B] <branch_name> [<commit>] [--track <track>].
Examples
1. repo = LibGit2.GitRepo(repo_path)
2. LibGit2.branch!(repo, "new_branch", set_head=false)
LibGit2.checkout! — Function
1. checkout!(repo::GitRepo, commit::AbstractString=""; force::Bool=true)
Equivalent to git checkout [-f] --detach <commit>. Checkout the git commit commit (a GitHash in string form) in repo. If force is true, force the checkout and discard any current changes. Note that this detaches the current HEAD.
Examples
1. repo = LibGit2.init(repo_path)
2. open(joinpath(LibGit2.path(repo), "file1"), "w") do f
3. write(f, "111
4. ")
5. end
6. LibGit2.add!(repo, "file1")
7. commit_oid = LibGit2.commit(repo, "add file1")
8. open(joinpath(LibGit2.path(repo), "file1"), "w") do f
9. write(f, "112
10. ")
11. end
12. # would fail without the force=true
13. # since there are modifications to the file
14. LibGit2.checkout!(repo, string(commit_oid), force=true)
LibGit2.clone — Function
1. clone(repo_url::AbstractString, repo_path::AbstractString, clone_opts::CloneOptions)
Clone the remote repository at `repo_url
(本文超出站点单文档体积上限,已截断)
