LibGit2

LibGit2.Buffer

libgit2 からデータをエクスポートするときに利用されるデータバッファです。git_buf 構造体に対応します。

通常 libgit2 からデータのフェッチは次のように行います:

buf_ref = Ref(Buffer())
@check ccall(..., (Ptr{Buffer},), buf_ref)
# buf_ref を使った処理
free(buf_ref)

Ref オブジェクトに対して最後に LibGit2.free を呼ぶ必要がある点に特に注意が必要です。

LibGit2.CheckoutOptions

git_checkout_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• checkout_strategy: 衝突の処理方法、および欠損ファイルのチェックアウト/再作成を強制するかどうかを制御する。
• disable_filters: ゼロでない値を指定すると、UNIX と DOS の間で改行文字 (CRLF など) を変換するフィルタが適用されない。
• dir_mode: チェックアウト処理に関わる任意のディレクトリに対する読み込み/書き込み/アクセスの権限。デフォルトでは 0755 となる。
• file_mode: チェックアウト処理に関わる任意のファイルに対する読み込み/書き込み/実行の権限。デフォルトではファイルが blob かどうかに応じて 0755 または 0644 となる。
• file_open_flags: チェックアウト中に任意のファイルを開くときに使われるビットフラグ。
• notify_flags: ユーザーに通知すべき衝突の種類を表すフラグ。
• notify_cb: チェックアウトで衝突が起きたことをユーザーに通知する省略可能なコールバック関数。この関数がゼロでない値を返すと、チェックアウトはキャンセルされる。
• notify_payload: 通知を行うコールバック関数に対するペイロード。
• progress_cb: チェックアウトの進捗を表示するための省略可能なコールバック関数。
• progress_payload: チェックアウトの進捗を表示するコールバック関数に対するペイロード。
• paths: 空でないなら、チェックアウト中に検索するパスを表す。空なら、チェックアウトはレポジトリの全てのファイルに対して行われる。
• baseline: workdir が持つはずの内容を、GitTree へのポインタとして保持したもの。デフォルトでは HEAD にあるツリーの状態を指す。
• baseline_index: workdir が持つはずの内容を、GitIndex へのポインタとして保持したもの。デフォルトでは HEAD にあるインデックスの状態が保持される。
• target_directory: 空でないなら、workdir ではなくこのディレクトリをチェックアウトする。
• ancestor_label: 衝突が起こったときに使われる、共通の祖先の側を表す名前。
• our_label: 衝突が起こったときに使われる、"こちら側" を表す名前。
• their_label: 衝突が起こったときに使われる、"あちら側" を表す名前。
• perfdata_cb: 性能データを表示するための省略可能なコールバック関数。
• perfdata_payload 性能データを表示するコールバック関数に対するペイロード。

LibGit2.CloneOptions

git_clone_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• checkout_opts: クローンの一環としてリモートのチェックアウトを行うときのオプション。
• fetch_opts: checkout_opts: クローンの一環としてリモートからチェックアウトする前に行うフェッチで使うオプション。
• bare: 0 だと、リモートレポジトリを完全にクローンする。0 でないと、bare なクローンを行う。つまりレポジトリに含まれるソースファイルのローカルコピーは作成されず、gitdir と workdir が同じになる。
• localclone: ローカルオブジェクトデータベースをクローンするか、フェッチしてから構築するかを指定するフラグ。デフォルトだと libgit2 に決めさせる。libgit2 はローカルクローンに対しては git の情報を使った転送を利用しないが、file:// で始まる URL に対しては利用する。
• checkout_branch: チェックアウトするブランチの名前。空文字列だと、リモートのデフォルトブランチがチェックアウトされる。
• repository_cb: クローンが作られる新しいレポジトリを作成するのに使われる省略可能なコールバック。
• repository_cb_payload: レポジトリコールバックに対するペイロード。
• remote_cb: クローン元のリモートを表す GitRemote を作成するために使われる省略可能なコールバック。
• remote_cb_payload: リモートコールバックに対するペイロード。

LibGit2.DescribeOptions

git_describe_options 対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• max_candidates_tags: refs/tags に含まれる直近 max_candidates_tags 個のタグがコミットを説明している可能性があるとみなされる。デフォルトでは 10 であり、直近 10 個のタグに対してそれがコミットを表すかどうかの判定が行われる。
• describe_strategy: refs/tags の全要素を考慮する (git-describe --tags と等価に振る舞う) か、refs/ の全要素を考慮する (git-describe --all と等価に振る舞う) かを制御する。
• pattern: pattern にマッチするタグだけを考慮する。glob 展開をサポートする。
• only_follow_first_parent: マッチした参照/タグから記述されるオブジェクトの距離を計算するとき、直接の親からの距離だけを考える。
• show_commit_oid_as_fallback: コミットを記述する参照が見つからない場合に、エラーを送出せずにコミットの GitHash を表示する (デフォルトの振る舞い)。

LibGit2.DescribeFormatOptions

git_describe_format_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• abbreviated_size: GitHash を省略して表示するときの文字数の下限。デフォルトでは 7 となる。
• always_use_long_format: 1 に設定すると、短いフォーマットが使われる場所であっても長いフォーマットが使われるようになる。
• dirty_suffix: 設定すると、workdir がダーティなときにこの文字列が説明文の最後に付くようになる。

LibGit2.DiffDelta

一つのエントリーに対する変更を記述する構造体です。git_diff_delta 構造体に対応します。

フィールドは次の通りです:

• status: Consts.DELTA_STATUS のいずれか。ファイルが追記/変更/削除されたかどうかを示す。
• flags: デルタの両側のオブジェクトおよびデルタ自身に関するフラグ。ファイルをバイナリとテキストのどちらとして扱うべきか、ファイルが diff のどちら側に存在するのか、オブジェクト ID の正しさが確認されているかどうかを保持する。
• similarity: ファイルが改名またはコピーされたかどうかを示すのに使われる。
• nfiles: デルタに含まれるファイルの個数 (例えばサブモジュールのコミット ID に対してデルタを計算すると、デルタに複数のファイルが含まれる場合がある)。
• old_file: 変更前のファイルに関する情報を含む DiffFile 構造体。
• new_file: 変更後のファイルに関する情報を含む DiffFile 構造体。

LibGit2.DiffFile

デルタの片側を記述する構造体です。git_diff_file 構造体に対応します。

フィールドは次の通りです:

• id: diff に含まれる要素の GitHash の値。この DiffFile が表す diff の側が空 (例えば diff がファイルの削除を表す) なら GitHash(0) となる。
• path: レポジトリのワーキングディレクトリを起点とした、この DiffFile が表す要素の相対パス (NULL 終端)。
• size: 要素のサイズ (単位はバイト)。
• flags: git_diff_flag_t フラグの組み合わせ。この整数の i 番目のビットが i 番目のフラグを設定する。
• mode: 要素に対する stat モード。
• id_abbrev: id フィールドを string に変換したときの長さ。通常 OID_HEXSZ (40) に等しい。libgit2 のバージョン 0.25.0 以降にのみ存在する。

LibGit2.DiffOptionsStruct

git_diff_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• flags: diff に表示されるファイルを制御するフラグ。デフォルトでは DIFF_NORMAL となる。
• ignore_submodules: サブモジュールのファイルを diff に表示するかどうか。デフォルトは SUBMODULE_IGNORE_UNSPECIFIED であり、これはサブモジュールが diff に表示されるかどうかがサブモジュールの設定によって制御されることを意味する。
• pathspec: diff に含めるファイルのパスを表すパターンの配列。レポジトリに含まれる全てのファイルを使うのがデフォルトとなる。
• notify_cb: ファイルデルタが追加されたときに diff の変更をユーザーに通知するための省略可能なコールバック。
• progress_cb: diff の進捗を表示するための省略可能なコールバック。0.24.0 以降の libgit2 でのみ意味を持つ。
• payload: notify_cb と progress_cb に渡すペイロード。
• context_lines: ハンクの端を定義する変更されていない行の個数。ハンクを表示するときに文脈を示すために前後に表示する行の個数でもある。デフォルトでは 3 となる。
• interhunk_lines: 二つの異なるハンクの間にある変更されていない行数がこの値以下だと、二つのハンクは合成される。デフォルトでは 0 となる。
• id_abbrev: GitHash を省略形で出力するときの長さ。デフォルトでは 7 となる。
• max_size: blob の最大ファイルサイズ。このサイズを超えたファイルはバイナリ blob として扱われる。デフォルトでは 512 MB となる。
• old_prefix: diff の片側にある古いファイルを配置するための仮想ファイルディレクトリの名前。デフォルトでは "a" となる。
• new_prefix: diff の片側にある新しいファイルを配置するための仮想ファイルディレクトリの名前。デフォルトでは "b" となる。

LibGit2.FetchHead

フェッチされた HEAD に関する情報を保持します。フェッチを行うブランチの URL や名前、HEAD がローカルにマージされているかどうかといった情報が含まれます。

フィールドは次の通りです:

• name: フェッチヘッドのローカル参照データベースの名前。例えば "refs/heads/master" など。
• url: フェッチヘッドの URL。
• oid: フェッチヘッドの先端の GitHash の値。
• ismerge: リモートの変更がローカルコピーにマージされたかどうかを示す真偽値フラグ。この値が true なら、リモートのフェッチヘッドの最新版がローカルコピーにある。

LibGit2.FetchOptions

git_fetch_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• callbacks: フェッチの間に使われるリモートコールバック。
• prune: フェッチの後に prune を実行するかどうか。デフォルトでは GitConfig にある設定が使われる。
• update_fetchhead: フェッチの後に FetchHead を更新するかどうか。デフォルトでは更新を実行する。これは git の通常の振る舞いとなっている。
• download_tags: リモートが持つタグをダウンロードするかどうか。デフォルトでは、サーバーからいずれにせよダウンロードされるオブジェクトに対するタグをリクエストする。
• proxy_opts: プロキシを通してリモートに接続するときのオプション。ProxyOptions を参照。0.25.0 よりも新しいバージョンの libgit2 にのみ存在する。
• custom_headers: フェッチに必要な追加ヘッダー。0.24.0 よりも新しいバージョンの libgit2 にのみ存在する。

GitAnnotated(repo::GitRepo, commit_id::GitHash)
GitAnnotated(repo::GitRepo, ref::GitReference)
GitAnnotated(repo::GitRepo, fh::FetchHead)
GitAnnotated(repo::GitRepo, comittish::AbstractString)

注釈が付いた git コミットです。コミットに関連する情報を rebase と merge に追加で渡すために、コミットが検索された方法と検索された理由が付いています。例えば衝突しているファイルでは衝突を起こしているマージにおけるソースあるいはターゲットのブランチに関する情報を持ちます。GitAnnotated はリモートブランチの先端や GitReference で記述されたブランチヘッドを参照することもできます。例えば FetchHead が渡されたときは参照先がリモートブランチの先端になります。

GitBlame(repo::GitRepo, path::AbstractString; options::BlameOptions=BlameOptions())

レポジトリ repo の履歴から収集した変更情報を使って、path にあるファイルに対する GitBlame オブジェクトを構築します。GitBlame オブジェクトはどのファイルチャンクを誰がいつどのように変更したかに関する記録を持ちます。options はファイルの内容と調査するコミットをどのように分離するかを制御します ──詳細は BlameOptions を参照してください。

GitBlob(repo::GitRepo, hash::AbstractGitHash)
GitBlob(repo::GitRepo, spec::AbstractString)

hash/spec が指定する GitBlob オブジェクトを repo から取り出して返します。

• hash は完全なハッシュ (GitHash) と部分的なハッシュ (GitShortHash) のどちらでも構いません。
• spec はオブジェクトを記述するテキストです: git のドキュメントに利用可能な記法のリストがあるので参照してください。

GitCommit(repo::GitRepo, hash::AbstractGitHash)
GitCommit(repo::GitRepo, spec::AbstractString)

hash/spec が指定する GitCommit オブジェクトを repo から取り出して返します。

• hash は完全なハッシュ (GitHash) と部分的なハッシュ (GitShortHash) のどちらでも構いません。
• spec はオブジェクトを記述するテキストです: git のドキュメントに利用可能な記法のリストがあるので参照してください。

GitHash

sha-1 ハッシュに基づいた git オブジェクトの識別子です。20 バイトの文字列 (十六進 40 桁の数値) であり、レポジトリに含まれる GitObject を識別するのに使われます。

GitObject(repo::GitRepo, hash::AbstractGitHash)
GitObject(repo::GitRepo, spec::AbstractString)

hash/spec が指定するオブジェクト (GitCommit, GitBlob, GitTree, GitTag のいずれか) を repo から取り出して返します。

• hash は完全なハッシュ (GitHash) と部分的なハッシュ (GitShortHash) のどちらでも構いません。
• spec はオブジェクトを記述するテキストです: git のドキュメントに利用可能な記法のリストがあるので参照してください。

GitRemote(repo::GitRepo,
          rmt_name::AbstractString,
          rmt_url::AbstractString) -> GitRemote

名前と URL を使ってリモート git レポジトリを検索します。デフォルトのフェッチ refspec を利用します。

例

repo = LibGit2.init(repo_path)
remote = LibGit2.GitRemote(repo, "upstream", repo_url)

GitRemote(repo::GitRepo,
          rmt_name::AbstractString,
          rmt_url::AbstractString,
          fetch_spec::AbstractString) -> GitRemote

リモート git レポジトリを検索します。検索ではレポジトリの名前と URL に加えて、リモートからフェッチする方法 (例えばどのリモートブランチからフェッチするかなど) も指定します。

例

repo = LibGit2.init(repo_path)
refspec = "+refs/heads/mybranch:refs/remotes/origin/mybranch"
remote = LibGit2.GitRemote(repo, "upstream", repo_url, refspec)

GitRemoteAnon(repo::GitRepo, url::AbstractString) -> GitRemote

名前を使わずに URL だけを使ってリモート git レポジトリを検索します。

例

repo = LibGit2.init(repo_path)
remote = LibGit2.GitRemoteAnon(repo, repo_url)

LibGit2.GitRepo(path::AbstractString)

path にある git レポジトリを開きます。

LibGit2.GitRepoExt(path::AbstractString,
                   flags::Cuint = Cuint(Consts.REPOSITORY_OPEN_DEFAULT))

振る舞いを細かく制御した上で path にある git レポジトリを開きます (path を読み込むときカレントユーザーは特別なアクセスグループのメンバーでなくてはならないかどうか、など)。

GitRevWalker(repo::GitRepo)

git レポジトリ repo のリビジョン (コミット) を走査します。GitRevWalker はレポジトリに含まれるコミットのコレクションであり、map, count や反復をサポートします (例えば count を使って特定の著者によるコミットの割合を計算できます)。

cnt = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
    count((oid,repo)->(oid == commit_oid1),
           walker,
           oid=commit_oid1,
           by=LibGit2.Consts.SORT_TIME)
end

この実行例では、count が特定の GitHash を持つコミットの個数を数えています。GitHash はコミットごとにユニークなので、cnt は 1 になるはずです。

GitShortHash(hash::GitHash, len::Integer)

git オブジェクトの識別子の省略形です。ユニークであれば git オブジェクトの識別に利用できます。十六進数で表した hash の最初の len 桁からなり、他の桁は無視されます。

LibGit2.GitSignature

git_signature オブジェクトのポインタを包んだ Julia ラッパーです。

LibGit2.GitStatus(repo::GitRepo; status_opts=StatusOptions())

git レポジトリに含まれる各ファイルの状態に関する情報 (ファイルが変更されたかどうか、ステージされているかどうか、など) を収集します。status_opts は様々なオプションを設定するのに指定でき、例えば追跡していないファイルを考慮するかどうか、あるいはサブモジュールを含めるかどうかを設定できます。詳細は StatusOptions を参照してください。

GitTag(repo::GitRepo, hash::AbstractGitHash)
GitTag(repo::GitRepo, spec::AbstractString)

hash/spec が指定する GitTag オブジェクトを repo から取り出して返します。

• hash は完全なハッシュ (GitHash) と部分的なハッシュ (GitShortHash) のどちらでも構いません。
• spec はオブジェクトを記述するテキストです: git のドキュメントに利用可能な記法のリストがあるので参照してください。

GitTree(repo::GitRepo, hash::AbstractGitHash)
GitTree(repo::GitRepo, spec::AbstractString)

hash/spec が指定する GitTree オブジェクトを repo から取り出して返します。

• hash は完全なハッシュ (GitHash) と部分的なハッシュ (GitShortHash) のどちらでも構いません。
• spec はオブジェクトを記述するテキストです: git のドキュメントに利用可能な記法のリストがあるので参照してください。

LibGit2.IndexEntry

インデックスに含まれるファイルエントリーのメモリ上での表現です。git_index_entry 構造体に対応します。

LibGit2.IndexTime

git_index_time 構造体に対応します。

LibGit2.BlameOptions

git_blame_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• flags: Consts.BLAME_NORMAL または Consts.BLAME_FIRST_PARENT (他の blame フラグは libgit2 によって実装されていない)。
• min_match_characters: ある変更が考えているコミットに関連付けられるために必要な最小の文字数。デフォルトでは 20 となる。Consts.BLAME_*_COPIES フラグのいずれかが使われたときにだけ意味を持つが、libgit2 はこれらのフラグをまだ実装していない。
• newest_commit: blame に含める最も新しいコミットの GitHash の値。
• oldest_commit: blame に含める最も古いコミットの GitHash の値。
• min_line: blame に含める最初の行番号。デフォルトでは 1 となる。
• max_line: blame に含める最後の行番号。デフォルトではファイルの末尾を表す 0 となる。

LibGit2.MergeOptions

git_merge_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• flags: マージの振る舞いを表す列挙体。git_merge_flag_t で定義される。対応する Julia の列挙体は GIT_MERGE であり、次の値を持つ:
  • MERGE_FIND_RENAMES: 共通の祖先とマージの "こちら側" あるいは "あちら側" の間でファイルの改名を検出するかどうか。ファイルが改名されるマージを許可する。
  • MERGE_FAIL_ON_CONFLICT: 衝突を検出したとき、解決しようとせずにすぐ終了する。
  • MERGE_SKIP_REUC マージで生まれるインデックスに REUC extension を書き込まない。
  • MERGE_NO_RECURSIVE: マージされるコミットが複数のマージ元を持つとき、それらを再帰的にマージせずに最初のものだけを使う。
• rename_threshold: 二つのファイルがどれだけ似ているときに改名されたかとみなすかを制御する基準値。一致度を示すパーセンテージを表す整数に設定される。デフォルトでは 50 となる。
• target_limit: 改名先のファイルとして検索・比較するファイルの最大個数。デフォルトでは 200 となる。
• metric: 二つのファイルの一致度を計算する、省略可能な独自の関数。改名の検出で利用される。
• recursion_limit: 行おうとしているマージに対する新しい仮想的なマージ元を作成しようとするときの、共通祖先に対するマージ回数の上限。デフォルトでは制限はない。このフィールドは 0.24.0 以降の libgit2 にのみ存在する。
• default_driver: 両側が変更されているときのマージドライバ。このフィールドは 0.25.0 以降の libgit2 にのみ存在する。
• file_favor: text ドライバが衝突したファイルを処理する方法。
  • MERGE_FILE_FAVOR_NORMAL: マージの両側が同じ部分への変更を持つとき git checkout はマージファイルの作成で使うインデックスに衝突が起きたことを示す情報を書き込む。ユーザーはこの情報を参照して衝突を解決する。デフォルトではこれが使われる。
  • MERGE_FILE_FAVOR_OURS: マージの両側が同じ部分への変更を持つとき、インデックスにおける "こちら側" のバージョンを使う。
  • MERGE_FILE_FAVOR_THEIRS: マージの両側が同じ部分への変更を持つとき、インデックスにおける "あちら側" のバージョンを使う。
  • MERGE_FILE_FAVOR_UNION: マージの両側が同じ部分への変更を持つとき、両方から一行ずつ取ってインデックスに書き込もうとしているファイルに含める。
• file_flags: ファイルをマージするときの指針を表す。

LibGit2.ProxyOptions

プロキシを通して接続するときのオプションです。

git_proxy_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• proxytype: 利用するプロキシの種類を表す列挙体。git_proxy_t で定義される。対応する Julia の列挙体は GIT_PROXY であり、次の値を持つ:
  • PROXY_NONE プロキシを通した接続を行わない。
  • PROXY_AUTO: プロキシの設定を git の設定から構築しようと試みる。
  • PROXY_SPECIFIED: この構造体の url フィールドに与えられる URL を使って接続する。
  デフォルトではプロキシの種類が自動検出される。
• url: プロキシの URL。
• credential_cb: 接続時にリモートが認証を要求したときに呼ばれるコールバック関数へのポインタ。
• certificate_cb: 証明書の検証に失敗したときに呼ばれるコールバック関数へのポインタ。この関数を受けたユーザーは接続するかどうかを自身で選択できる。接続はこの関数が 1 を返すと許可され、0 を返すと許可されない。負の値を返すとエラーが発生する。
• payload: 二つのコールバック関数に渡されるペイロード。

例

julia> fo = LibGit2.FetchOptions(
         proxy_opts = LibGit2.ProxyOptions(url=Cstring("https://my_proxy_url.com")))

julia> fetch(remote, "master", options=fo)

LibGit2.PushOptions

git_push_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• parallelism: パックファイルを作成しなければならないときにパックビルダーが起動するワーカースレッドの個数を設定する。0 にすると、パックビルダーがスレッドの個数を自動的に設定する。デフォルトでは 1 となる。
• callbacks: プッシュで使う (リモートの認証などを行う) コールバック。
• proxy_opts: リモートとのやり取りで使うプロキシのオプション。詳細は ProxyOptions を参照。0.25.0 以降の libgit2 でのみ意味を持つ。
• custom_headers: プッシュ操作で必要となる追加のヘッダー。0.24.0 以降の libgit2 でのみ意味を持つ。

LibGit2.RebaseOperation

rebase で行われる単一の命令/操作を表します。git_rebase_operation 構造体に対応します。

フィールドは次の通りです:

• optype: 現在行われている rebase 操作の種類。次のいずれか:
  • REBASE_OPERATION_PICK: 考えているコミットを cherry-pick する。
  • REBASE_OPERATION_REWORD: 考えているコミットを cherry-pick する。そのときプロンプトを使ってコミットメッセージを書き換える。
  • REBASE_OPERATION_EDIT: 考えているコミットを cherry-pick する。そのときコミットの内容とメッセージの書き換えをユーザーに行わせる。
  • REBASE_OPERATION_SQUASH: 考えているコミットと一つ前のコミットを squash する。二つのコミットのメッセージは合併される。
  • REBASE_OPERATION_FIXUP: 考えているコミットと一つ前のコミットを squash する。前のコミットのメッセージだけが残る。
  • REBASE_OPERATION_EXEC: コミットを cherry-pick しない。コマンドを実行し、正常に終了したら次の処理に移る。
• id: この rebase ステップが操作しているコミットの GitHash の値。
• exec: REBASE_OPERATION_EXEC が使われた場合に、このステップで実行されるコマンド (例えば各コミットの後にテストスイートを実行するなど)。

LibGit2.RebaseOptions

git_rebase_options 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• quiet: 同じ rebsae に手を貸している他の git クライアントに、この rebase は "静かに" 行われるべきであることを伝える。相互運用のために使われる。デフォルトでは 1 となる。
• inmemory: インメモリの rebase を開始する。rebase を行う呼び出し側はステップを実行して任意の変更をコミットして構わないが、HEAD のリワインドやレポジトリの更新をしてはいけない。workdir は変更されない。0.24.0 以降の libgit2 にだけ存在する。
• rewrite_notes_ref: rebase が終了したときにコミットノートを書き換えるのに使われるノートへの参照。
• merge_opts: 各 rebase ステップでツリーがどのようにマージされるかを制御するマージオプション。0.24.0 以降の libgit2 にだけ存在する。
• checkout_opts: rebase の初期化、rebase ステップの実行、rebase 中断でファイルに書き込むときの checkout オプション。詳細は CheckoutOptions を参照。

LibGit2.RemoteCallbacks

コールバックの設定です。git_remote_callbacks 構造体に対応します。

LibGit2.SignatureStruct

コミッターやタガーの署名です。git_signature 構造体に対応します。

フィールドは次の通りです:

• name: コミッターあるいはコミットのオーサーのフルネーム。
• email: コミッター/オーサーに連絡できる電子メールアドレス。
• when: コミットがレポジトリにコミット/オーサーされた時刻を表す TimeStruct の値。

LibGit2.StatusEntry

HEAD に存在するファイルとインデックスに存在するファイルの差異、およびインデックスに存在するファイルとワーキングディレクトリに存在するファイルの差異を表します。git_status_entry 構造体に対応します。

フィールドは次の通りです:

• status: ファイルに対する状態フラグ。ファイルが現在もそのまま存在するか、それともインデックスまたはワークツリーで変更されたかを表す。
• head_to_index: HEAD に存在するファイルとインデックスに存在するファイルの間の差異を表す DiffDelta へのポインタ。
• index_to_workdir: インデックスに存在するファイルと workdir に存在するファイルの間の差異を表す DiffDelta へのポインタ。

LibGit2.StatusOptions

git_status_foreach_ext() がコールバックを呼び出す方法を制御するためのオプションです。git_status_opt_t 構造体に対応します。

フィールドは次の通りです:

• version: 使われている構造体のバージョン。将来この構造体が変更されたときのために用意されている。現在は必ず 1 となる。
• show: 確認すべきファイルと順序を示すフラグ。Consts.STATUS_SHOW_INDEX_AND_WORKDIR がデフォルトで使われる。
• flags: ステータスコールで使われるコールバックを制御するフラグ。
• pathspec: パスのマッチングで使われるパスの配列。パスマッチングの振る舞いは show と flags の値によって変化する。
• baseline: ワーキングディレクトリとインデックスを比較するときに使われるツリー。デフォルトでは HEAD が使われる。0.27.0 以降の libgit2 にだけ存在する ¹。

LibGit2.StrArrayStruct

libgit2 が使う文字列配列の表現です。git_strarray 構造体に対応します。

libgit2 からデータをフェッチするとき、通常は次のようにします:

sa_ref = Ref(StrArrayStruct())
@check ccall(..., (Ptr{StrArrayStruct},), sa_ref)
res = convert(Vector{String}, sa_ref[])
free(sa_ref)

Ref オブジェクトに対して最後に LibGit2.free を呼ぶ必要がある点に特に注意が必要です。

逆に文字列のベクトルを libgit2 に渡すときは、暗黙の変換を使うのが通常は最も簡単です:

strs = String[...]
@check ccall(..., (Ptr{StrArrayStruct},), strs)

strs のデータは Julia によってアロケートされるために free が必要ないことに注意してください。

LibGit2.TimeStruct

署名に含まれる時刻です。git_time 構造体に対応します。

add!(repo::GitRepo, files::AbstractString...;
     flags::Cuint = Consts.INDEX_ADD_DEFAULT)
add!(idx::GitIndex, files::AbstractString...;
     flags::Cuint = Consts.INDEX_ADD_DEFAULT)

files が指定するパスを持つファイルを全て、インデックス idx (あるいは repo のインデックス) に追加します。追加するファイルがインデックスに存在するならインデックスエントリーが更新され、追加するファイルがインデックスに存在しないならインデックスに新しく追加されます。files には glob パターンを指定でき、そうするとマッチするファイルが全て追加されます (後述する INDEX_ADD_DISABLE_PATHSPEC_MATCH を使うと glob を無効化できます)。.gitignore または .gitconfig で無視されているファイルは基本的に追加されません。ただし、そのファイルが既にインデックスへ追加されているときは例外で、そのときは追加されます。

キーワード引数 flags は無視されるファイルの取り扱いを制御するビットフラグの集合です:

• Consts.INDEX_ADD_DEFAULT: デフォルト。振る舞いは上述の通り。
• Consts.INDEX_ADD_FORCE: 既存の無視規則を無効化し、無視されているファイルのインデックスへの追加を強制する。
• Consts.INDEX_ADD_CHECK_PATHSPEC: INDEX_ADD_FORCE と同時には設定できない。files の中でディスクに存在する全てのファイルが、無視されるファイルのリストに入っていないことを確認する。いずれかのファイルが無視されるファイルのリストに入っているとき、この関数は EINVALIDSPEC を返す。
• Consts.INDEX_ADD_DISABLE_PATHSPEC_MATCH: glob マッチングを無効化し、files で指定されるパスと正確に一致するファイルだけをインデックスに追加する。

add_fetch!(repo::GitRepo, rmt::GitRemote, fetch_spec::String)

指定されたリモートレポジトリ rmt に対するフェッチ refspec を追加します。この refspec はフェッチを行うブランチの情報を保持します。

例

julia> LibGit2.add_fetch!(repo, remote, "upstream");

julia> LibGit2.fetch_refspecs(remote)
String["+refs/heads/*:refs/remotes/upstream/*"]

add_push!(repo::GitRepo, rmt::GitRemote, push_spec::String)

指定されたリモートレポジトリ rmt に対するプッシュ refspec を追加します。この refspec はプッシュを行うブランチの情報を保持します。

例

julia> LibGit2.add_push!(repo, remote, "refs/heads/master");

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, branch);

julia> LibGit2.push_refspecs(remote)
String["refs/heads/master"]

LibGit2.addblob!(repo::GitRepo, path::AbstractString)

path にあるファイルを読み、それを loose blob として repo のオブジェクトデータベースに追加します。読み込んだ blob の GitHash を返します。

例

hash_str = string(commit_oid)
blob_file = joinpath(repo_path, ".git", "objects", hash_str[1:2], hash_str[3:end])
id = LibGit2.addblob!(repo, blob_file)

author(c::GitCommit)

コミット c のオーサーの Signature を返します。オーサーとはコミットが表すファイルへの変更を行った人物のことです。committer も参照してください。

authors(repo::GitRepo) -> Vector{Signature}

レポジトリ repo に対するコミットのオーサー全員の Signature を返します。

例

repo = LibGit2.GitRepo(repo_path)
repo_file = open(joinpath(repo_path, test_file), "a")

println(repo_file, commit_msg)
flush(repo_file)
LibGit2.add!(repo, test_file)
sig = LibGit2.Signature("TEST", "TEST@TEST.COM", round(time(), 0), 0)
commit_oid1 = LibGit2.commit(repo, "commit1"; author=sig, committer=sig)
println(repo_file, randstring(10))
flush(repo_file)
LibGit2.add!(repo, test_file)
commit_oid2 = LibGit2.commit(repo, "commit2"; author=sig, committer=sig)

# [sig, sig] のベクトルとなる。
auths = LibGit2.authors(repo)

branch(repo::GitRepo)

git branch と等価です。現在の HEAD から新しいブランチを作成します。

branch!(repo::GitRepo,
        branch_name::AbstractString,
        commit::AbstractString="";
        kwargs...)

新しい git ブランチをチェックアウトします。commit は文字列形式の GitHash であり、新しいブランチの開始地点を表します。

キーワード引数は次の通りです:

• track::AbstractString="": 新しいブランチが追跡すべきリモートブランチが存在するなら、その名前を表す。空 (デフォルト) なら、リモートブランチは追跡されない。
• force::Bool=false: true だと、ブランチの作成が強制される。
• set_head::Bool=true: true だと、作成が完了したブランチのヘッドが repo の HEAD として設定される。

この関数は git checkout [-b|-B] <branch_name> [<commit>] [--track <track>] と等価です。

例

repo = LibGit2.GitRepo(repo_path)
LibGit2.branch!(repo, "new_branch", set_head=false)

checkout!(repo::GitRepo, commit::AbstractString=""; force::Bool=true)

git checkout [-f] --detach <commit> と等価です。repo に含まれる git コミット commit (文字列形式の GitHash) をチェックアウトします。force が true だと、現在の変更を破棄してチェックアウトを強制的に行います。この操作により現在の HEAD が切り離される (detached になる) ことに注意してください。

例

repo = LibGit2.init(repo_path)
open(joinpath(LibGit2.path(repo), "file1"), "w") do f
    write(f, "111
")
end
LibGit2.add!(repo, "file1")
commit_oid = LibGit2.commit(repo, "add file1")
open(joinpath(LibGit2.path(repo), "file1"), "w") do f
    write(f, "112
")
end
# ファイルが変更されているので、force=true としないと失敗する。
LibGit2.checkout!(repo, string(commit_oid), force=true)

clone(repo_url::AbstractString, repo_path::AbstractString, clone_opts::CloneOptions)

repo_url にあるリモートレポジトリを repo_path にクローンします。repo_url にはリモート URL またはローカルファイルシステムのパスを指定でき、repo_path にはローカルファイルシステムのパスだけを指定できます。クローンが bare かどうかなどを指定するオプションは CloneOptions で設定されます。

例

repo_url = "https://github.com/JuliaLang/Example.jl"
repo = LibGit2.clone(repo_url, "/home/me/projects/Example")

clone(repo_url::AbstractString, repo_path::AbstractString; kwargs...)

repo_ul にあるリモートレポジトリをローカルファイルシステムの位置 repo_path にクローンします。

キーワード引数は次の通りです:

• branch::AbstractString="": クローンするリモートのブランチ。デフォルトではレポジトリのデフォルトブランチ (たいていは master) が使われる。
• isbare::Bool=false: true にすると、リモートレポジトリが bare レポジトリとしてクローンされる。つまり repo_path/.git ではなく repo_path 自身が git ディレクトリとなる。これはワーキングツリーをチェックアウトできないことを意味する。git CLI の引数 --bare と同じ意味を持つ。
• remote_cb::Ptr{Cvoid}=C_NULL: クローンする前にリモートを作成するときに使われるコールバック。C_NULL (デフォルト値) だとリモートは既に存在するものとみなされ作成されない。
• credentials::Creds=nothing: プライベートレポジトリに対して認証を行うときの資格情報や設定を提供する。
• callbacks::Callbacks=Callbacks(): ユーザーが提供するコールバックとペイロード。

この関数は git clone [-b <branch>] [--bare] <repo_url> <repo_path> と等価です。

例

repo_url = "https://github.com/JuliaLang/Example.jl"
repo1 = LibGit2.clone(repo_url, "test_path")
repo2 = LibGit2.clone(repo_url, "test_path", isbare=true)
julia_url = "https://github.com/JuliaLang/julia"
julia_repo = LibGit2.clone(julia_url, "julia_path", branch="release-0.6")

commit(repo::GitRepo, msg::AbstractString; kwargs...) -> GitHash

git_commit_create のラッパーです。msg をコミットメッセージとしてレポジトリ repo にコミットを作成します。新しいコミットの OID を返します。

キーワード引数は次の通りです:

• refname::AbstractString=Consts.HEAD_FILE: NULL でないとき、コミットの後にこの名前の参照が新しいコミットを指すよう更新される。例えば "HEAD" とすれば、コミットの後に現在のブランチの HEAD が更新される。参照が存在しなければ新しく作成される。
• author::Signature = Signature(repo): コミットをオーサーした人物に関する情報が含まれる。
• committer::Signature = Signature(repo): コミットをレポジトリにコミットした人物の情報が含まれる。author と必ずしも同じとは限らない。例えば author からメールを受け取った commiter がコミットした場合は committer と author が異なる。
• tree_id::GitHash = GitHash(): コミットの作成に使う git ツリー。コミットの祖先や他の履歴との関係を示す。このツリーは repo に属する必要がある。
• parent_ids::Vector{GitHash}=GitHash[]: 新しいコミットの親となるコミットの GitHash のリスト。空でも構わない。例えばマージコミットでは複数の親コミットが存在する。

LibGit2.commit(rb::GitRebase, sig::GitSignature)

リベース rb に対して現在のパッチをコミットします。sig はコミッターを表します。コミットが既に適用されていれば静かに実行されます。

committer(c::GitCommit)

コミット c のコミッターの Signature を返します。コミッターは author によって書かれた変更をコミットした人物であり、author と同じである必要はありません。例えば author からメールで受け取ったパッチを committer がコミットした場合は author と committer が異なります。

LibGit2.count(f::Function,
              walker::GitRevWalker;
              oid::GitHash=GitHash(),
              by::Cint=Consts.SORT_NONE,
              rev::Bool=false)

GitRevWalker 型の値 walker を使ってレポジトリの履歴に含まれる全てのコミットを走査し、f が true を返すコミットの個数を返します。

キーワード引数は次の通りです:

• oid: 走査を始めるコミットの GitHash の値。デフォルトの値を使うと push_head! が呼び出され、HEAD のコミットから始まってその祖先が全て走査される。
• by: ソートメソッド。デフォルトではソートを行わない。他の選択肢にはトポロジカル順序 (LibGit2.Consts.SORT_TOPOLOGICAL)・時間に沿って前向き (LibGit2.Consts.SORT_TIME, 古いものが先)・時間に沿って後ろ向き (LibGit2.Consts.SORT_REVERSE, 新しいものが先) がある。
• rev: ソートの後に順序を逆転させるかどうか (トポロジカル順序を逆転させる場合など)。

例

cnt = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
    count((oid, repo)->(oid == commit_oid1),
           walker,
           oid=commit_oid1,
           by=LibGit2.Consts.SORT_TIME)
end

このコードの count は GitHash の値が commit_oid1 のコミットから新しいコミットに向かって走査し、GitHash が commit_oid1 に等しいコミットの個数を計算します。GitHash はコミットごとにユニークなので、cnt は 1 となります。

counthunks(blame::GitBlame)

ファイルに含まれる異なる "ハンク" の個数を返します。ハンクは複数の行からなることもあります。ハンクは通常まとめて追加/変更/削除されたファイルの一部を表し、例えばソースファイルに追加された関数や最適化された内部ループがハンクとなります。

LibGit2.create_branch(repo::GitRepo,
                      bname::AbstractString,
                      commit_obj::GitCommit; force::Bool=false)

レポジトリ repo にコミット commit_obj を指す bname という名前の新しいブランチを作成します。repo は commit_obj を含む必要があります。force が true だと、bname という名前のブランチが存在していたとしても上書きします。force が false だと、bname という名前のブランチが存在するときエラーとなります。

credential_callback(libgit2credptr::Ptr{Ptr{Cvoid}},
                    url_ptr::Cstring,
                    username_ptr::Cstring,
                    allowed_types::Cuint,
                    p::CredentialPayload) -> Cint

接続プロトコルに応じて異なる資格情報の取得機能を提供する libgit2 のコールバック関数です²。p は状態と設定を記録する LibGit2.CredentialPayload オブジェクトを表します。

allowed_types は試行すべき認証メソッドを指定する LibGit2.Consts.GIT_CREDTYPE のビットマスクです。

資格情報の認証は (サポートされていれば) 次の順序で行われます:

• SSH エージェント
• SSH の秘密鍵/公開鍵ペア
• プレーンテキストのユーザーネーム/パスワード

ユーザーに表示される認証プロンプトは ^D をタイプする (コントロールキーを押しながら d キーを押す) ことで中断できます。

詳細は libgit2 のガイド Authenticating against a server を参照してください。

credentials_cb()

credentials_callback に対する C 関数ポインタです³。

default_signature(repo::GitRepo)

シグネチャオブジェクトを返します。使い終わったら解放が必要です。

LibGit2.delete_branch(branch::GitReference)

branch が指すブランチを削除します。

diff_files(repo::GitRepo, branch1::AbstractString,
           branch2::AbstractString; kwarg...) -> Vector{AbstractString}

git レポジトリ repo の branch1 と branch2 で異なるファイルを返します。

キーワード引数は次の通りです:

• filter::Set{Consts.DELTA_STATUS}: diff に対するオプション。デフォルトでは追加・変更・削除されたファイルを表示する。

変更されたファイルの名前だけを返します。内容は返しません。

例

LibGit2.branch!(repo, "branch/a")
LibGit2.branch!(repo, "branch/b")
# repo にファイルを追加する。
open(joinpath(LibGit2.path(repo),"file"),"w") do f
    write(f, "hello repo
")
end
LibGit2.add!(repo, "file")
LibGit2.commit(repo, "add file")
# ["file"] が返る。
filt = Set([LibGit2.Consts.DELTA_ADDED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)
# 既存のファイルは変更されていないので [] が返る。
filt = Set([LibGit2.Consts.DELTA_MODIFIED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)

この関数は git diff --name-only --diff-filter=<filter> <branch1> <branch2> と等価です。

entryid(te::GitTreeEntry)

te が参照するオブジェクトの GitHash を返します。

entrytype(te::GitTreeEntry)

te が参照するオブジェクトの型を返します。返り値は objtype と同様であり、GitTree や GitBlob といった値です。

fetch(rmt::GitRemote, refspecs; options::FetchOptions=FetchOptions(), msg="")

指定されたリモート git レポジトリ rmt からフェッチを行います。フェッチするリモートブランチは refspec で決定されます。キーワード引数は次の通りです:

• options: フェッチのオプション。フェッチ後に prune するかどうかなどを決める。詳しくは FetchOptions を参照。
• msg: reflog に挿入するメッセージ。

fetch(repo::GitRepo; kwargs...)

レポジトリ repo の upstream から更新をフェッチします。

キーワード引数は次の通りです:

• remote::AbstractString="origin": フェッチする repo のリモートを指定する名前。remote を空にすると、URL を使って匿名リモートが構築される。
• remoteurl::AbstractString="": remote の URL。指定しないと、与えられた remote の名前から構築される。
• refspecs=AbstractString[]: フェッチのプロパティ。
• credentials=nothing: プライベートな remote に対して認証を行うときの資格情報や設定。
• callbacks=Callbacks(): ユーザーが提供するコールバックとペイロード。

この関数は git fetch [<remoteurl>|<repo>] [<refspecs>] と等価です。

fetchheads(repo::GitRepo) -> Vector{FetchHead}

repo のフェッチヘッドを全て羅列します。FetchHead 型には名前・URL・マージ状態などが含まれます。

例

julia> fetch_heads = LibGit2.fetchheads(repo);

julia> fetch_heads[1].name
"refs/heads/master"

julia> fetch_heads[1].ismerge
true

julia> fetch_heads[2].name
"refs/heads/test_branch"

julia> fetch_heads[2].ismerge
false

fetch_refspecs(rmt::GitRemote) -> Vector{String}

指定されたリモートレポジトリ rmt のフェッチ refspec を取得します。これらの refspec はフェッチで使うべきブランチに関する情報を保持します。

例

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, "upstream");

julia> LibGit2.add_fetch!(repo, remote, "upstream");

julia> LibGit2.fetch_refspecs(remote)
String["+refs/heads/*:refs/remotes/upstream/*"]

fetchhead_foreach_cb()

fetchhead_foreach_callback に対する C 関数ポインタです。

merge_base(repo::GitRepo, one::AbstractString, two::AbstractString) -> GitHash

コミット one と two の間のマージ元 (共通祖先) を見つけます。one と two は文字列形式でも構いません。マージ元の GitHash を返します。

merge!(repo::GitRepo; kwargs...) -> Bool

git merge をレポジトリ repo に対して行います。いくつかのコミットを分岐した履歴と共に現在のブランチにマージします。マージが成功すれば true を返し、成功しなければ false を返します。

キーワード引数は次の通りです:

• committish::AbstractString="": committish が示す名前の付いたコミットをマージする。
• branch::AbstractString="": ブランチ branch と、そのブランチに含まれるコミットで現在のブランチから分岐しているものを全てマージする。
• fastforward::Bool=false: true だと、マージがファストフォワードとなる (現在のブランチヘッドがマージされるコミットの祖先である) 場合にのみマージを実行し、そうでなければマージを拒否して false を返す。git CLI の --ff-only オプションと等価。
• merge_opts::MergeOptions=MergeOptions(): マージのオプションを指定する。衝突が起きたときのマージ戦略などが指定される。
• checkout_opts::CheckoutOptions=CheckoutOptions(): チェックアウトステップのオプションを指定する。

この関数は git merge [--ff-only] [<committish> | <branch>] と等価です。

merge!(repo::GitRepo, anns::Vector{GitAnnotated}; kwargs...) -> Bool

GitAnnotated オブジェクトとして表される注釈付きコミット anns から変更をレポジトリ repo の HEAD にマージします。キーワード引数は次の通りです:

• merge_opts::MergeOptions = MergeOptions(): どのようにマージを行うかを示すオプション。ファストフォワードが許されるかどうかなど。詳細は MergeOptions を参照。
• checkout_opts::CheckoutOptions = CheckoutOptions(): どのようにチェックアウトを行うかを示すオプション。詳細は CheckoutOptions を参照。

anns はリモートブランチまたはローカルブランチのヘッドを参照できます。マージが成功したときは true を返し、成功しなかったとき (例えばブランチが共通祖先を持たないときなど) は false を返します。

例

upst_ann = LibGit2.GitAnnotated(repo, "branch/a")

# ブランチをマージする。
LibGit2.merge!(repo, [upst_ann])

merge!(repo::GitRepo,
       anns::Vector{GitAnnotated},
       fastforward::Bool; kwargs...) -> Bool

GitAnnotated オブジェクトとして表される注釈付きコミット anns から変更をレポジトリ repo の HEAD にマージします。fastforward が true だと、ファストフォワードのマージだけが許されます。このとき衝突が起こると、マージは失敗します。fastforward が false なら、マージによってユーザーが解決する必要のある衝突ファイルが生成される可能性があります。

キーワード引数は次の通りです:

• merge_opts::MergeOptions = MergeOptions(): どのようにマージを行うかを示すオプション。ファストフォワードが許されるかどうかなど。詳細は MergeOptions を参照。
• checkout_opts::CheckoutOptions = CheckoutOptions(): どのようにチェックアウトを行うかを示すオプション。詳細は CheckoutOptions を参照。

anns はリモートブランチまたはローカルブランチのヘッドを参照できます。マージが成功したときは true を返し、成功しなかったとき (例えばブランチが共通祖先を持たないときなど) は false を返します。

例

upst_ann_1 = LibGit2.GitAnnotated(repo, "branch/a")

# ファストフォワードでマージする。
LibGit2.merge!(repo, [upst_ann_1], true)

# 衝突するマージ。
upst_ann_2 = LibGit2.GitAnnotated(repo, "branch/b")
# ファストフォワードを使ったマージを試みる。
LibGit2.merge!(repo, [upst_ann_2], true)  # false が返る
LibGit2.merge!(repo, [upst_ann_2], false) # true が返る

ffmerge!(repo::GitRepo, ann::GitAnnotated)

変更を現在の HEAD にファストフォワードでマージします。ann が指すコミットが現在の HEAD の子である場合 (例えばローカルブランチの先端の先にあるリモートブランチから変更を pull するときなど) にのみ行えます。

LibGit2.fullname(ref::GitReference)

シンボリック参照 ref が指す参照の名前を返します。ref がシンボリック参照でなければ空文字列を返します。

features()

現在のバージョンの libgit2 がサポートする git 機能 (スレッディングや HTTPS, SSH の利用など) のリストを返します。

filename(te::GitTreeEntry)

te が参照するディスク上のオブジェクトのファイル名を返します。

filemode(te::GitTreeEntry) -> Cint

te が参照するディスク上のオブジェクトの UNIX ファイルモードを返します。

LibGit2.gitdir(repo::GitRepo)

repo の "git" ファイルの場所を返します:

• 通常のレポジトリに対しては、.git フォルダの場所が返ります。
• bare なレポジトリに対しては、レポジトリ自身の場所が返ります。

workdir, path も参照してください。

LibGit2.git_url(; kwargs...) -> String

与えられた URL 要素から文字列を作成します。キーワード引数 scheme が与えられないと、scp 風の記法を使った URL が生成されます。

キーワード引数は次の通りです⁴:

• scheme::AbstractString="": 利用するプロトコルを識別する URL スキーム。HTTP では "http", SSH では "ssh" などとなる。scheme が与えられないと出力フォーマットは "ssh" となり、scp 風の記法が使われる。
• username::AbstractString="": 指定されれば、出力でユーザー名として使われる。
• host::AbstractString="": 出力で使うホスト名。ホスト名は指定される必要がある。
• port::Union{AbstractString,Integer}="": 指定されれば、出力でポート番号として使われる。scp 風の記法を使うときは指定できない。
• path::AbstractString="": 指定されれば、出力でパスとして使われる。

例

julia> LibGit2.git_url(username="git", host="github.com",
                       path="JuliaLang/julia.git")
"git@github.com:JuliaLang/julia.git"

julia> LibGit2.git_url(scheme="https", host="github.com",
                       path="/JuliaLang/julia.git")
"https://github.com/JuliaLang/julia.git"

julia> LibGit2.git_url(scheme="ssh", username="git", host="github.com",
                       port=2222, path="JuliaLang/julia.git")
"ssh://git@github.com:2222/JuliaLang/julia.git"

@githash_str -> AbstractGitHash

与えられた文字列から git ハッシュオブジェクトを構築します。返り値の型は文字列が十六進 40 桁未満のとき GitShortHash で、それ以外のとき GitHash です。

例

julia> LibGit2.githash"d114feb74ce633"
GitShortHash("d114feb74ce633")

julia> LibGit2.githash"d114feb74ce63307afe878a5228ad014e0289a85"
GitHash("d114feb74ce63307afe878a5228ad014e0289a85")

LibGit2.head(repo::GitRepo) -> GitReference

git レポジトリ repo が持つ現在の HEAD に対する GitReference を返します。

head(pkg::AbstractString) -> String

git レポジトリ pkg が持つ現在の HEAD の GitHash を文字列として返します。

LibGit2.head!(repo::GitRepo, ref::GitReference) -> GitReference

ref が指すオブジェクトを git レポジトリ repo の HEAD に設定します。

LibGit2.head_oid(repo::GitRepo) -> GitHash

git レポジトリ repo が持つ現在の HEAD のオブジェクト ID を検索します。

LibGit2.headname(repo::GitRepo)

git レポジトリ repo が持つ現在の HEAD の名前を検索します。repo が現在 detached なら、そうなる前の HEAD の名前を返します。

LibGit2.init(path::AbstractString, bare::Bool=false) -> GitRepo

新しい git レポジトリを path に開きます。bare が false だと、ワーキングツリーは path/.git に作成されます。bare が true だと、ワーキングディレクトリは作成されません。

is_ancestor_of(a::AbstractString, b::AbstractString, repo::GitRepo) -> Bool

a が b の祖先なら true を返します。a と b は文字列形式で表される GitHash です。

例

julia> repo = LibGit2.GitRepo(repo_path);

julia> LibGit2.add!(repo, test_file1);

julia> commit_oid1 = LibGit2.commit(repo, "commit1");

julia> LibGit2.add!(repo, test_file2);

julia> commit_oid2 = LibGit2.commit(repo, "commit2");

julia> LibGit2.is_ancestor_of(string(commit_oid1), string(commit_oid2), repo)
true

isbinary(blob::GitBlob) -> Bool

ヒューリスティックを使ってファイルがバイナリかどうかを推定します。推定は最初の 8000 バイトを調べ、ヌルバイトが存在することおよび出力可能文字と比べて出力不可能文字が無視できない頻度で出現することを確認するという方法で行われます。

iscommit(id::AbstractString, repo::GitRepo) -> Bool

git レポジトリ repo にコミット id が存在するかどうかを判定します。id は文字列形式の GitHash です。

例

julia> repo = LibGit2.GitRepo(repo_path);

julia> LibGit2.add!(repo, test_file);

julia> commit_oid = LibGit2.commit(repo, "add test_file");

julia> LibGit2.iscommit(string(commit_oid), repo)
true

LibGit2.isdiff(repo::GitRepo,
               treeish::AbstractString,
               pathspecs::AbstractString="";
               cached::Bool=false)

treeish で指定されるツリーとワーキングツリー (cached=false のとき) またはインデックス (cached=true のとき) の間に差異があるかどうかを判定します。pathspecs は diff に対するオプションの指定です。

例

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdiff(repo, "HEAD") # false
open(joinpath(repo_path, new_file), "a") do f
    println(f, "here's my cool new file")
end
LibGit2.isdiff(repo, "HEAD") # true になる。

この関数は git diff-index <treeish> [-- <pathspecs>] と等価です。

LibGit2.isdirty(repo::GitRepo,
                pathspecs::AbstractString="";
                cached::Bool=false) -> Bool

ワーキングツリー (cached = false のとき) またはインデックス (cached = false のとき) に含まれる追跡されるファイルに対する変更があるかどうかを判定します。pathspecs は diff に対するオプションの指定です。

例

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdirty(repo) # false
open(joinpath(repo_path, new_file), "a") do f
    println(f, "here's my cool new file")
end
LibGit2.isdirty(repo) # true になる。
LibGit2.isdirty(repo, new_file) # true になる。

この関数は git diff-index HEAD [-- <pathspecs>] と等価です。

LibGit2.isorphan(repo::GitRepo)

現在のブランチが "orphan" ブランチかどうか、つまりコミットを持たないかどうかを判定します。

isset(val::Integer, flag::Integer)

val の flag 番目のビットがセットされている (1) かセットされていない (0) かをテストします。

iszero(id::GitHash) -> Bool

与えられた GitHash の全ての十六進桁がゼロかどうかを判定します。

lookup_branch(repo::GitRepo,
              branch_name::AbstractString,
              remote::Bool=false) -> Union{GitReference, Nothing}

branch_name という名前のブランチが git レポジトリ repo に存在するかどうかを判定します。remote が true だと repo はリモート git レポジトリとみなされ、そうでなければ repo はローカルファイルシステムに存在するとみなされます。

要求されたブランチが存在すればそれを指す GitReference を返し、存在しなければ nothing を返します。

LibGit2.map(f::Function,
            walker::GitRevWalker;
            oid::GitHash=GitHash(),
            range::AbstractString="",
            by::Cint=Consts.SORT_NONE,
            rev::Bool=false)

GitRevWalker 型の値 walker を使って、レポジトリの履歴に含まれる全てのコミットを走査し、各コミットに f を適用します。

キーワード引数は次の通りです:

• oid: 走査を始めるコミットの GitHash の値。デフォルトの値を使うと push_head! が呼び出され、HEAD のコミットから始まってその祖先が全て走査される。
• range: oid1..oid2 という形式をした GitHash の区間。f はこの二つのコミットの間にある全てのコミットに適用される。
• by: ソートメソッド。デフォルトではソートを行わない。他の選択肢にはトポロジカル順序 (LibGit2.Consts.SORT_TOPOLOGICAL)・時間に沿って前向き (LibGit2.Consts.SORT_TIME, 古いものが先)・時間に沿って後ろ向き (LibGit2.Consts.SORT_REVERSE, 新しいものが先) がある。
• rev: ソートの後に順序を逆転させるかどうか (トポロジカル順序を逆転させる場合など)。

例

oids = LibGit2.with(LibGit2.GitRevWalker(repo)) do walker
    LibGit2.map((oid, repo)->string(oid), walker, by=LibGit2.Consts.SORT_TIME)
end

このコードの map は GitRevWalker を使って GitHash を取得しています。

mirror_callback(remote::Ptr{Ptr{Cvoid}}, repo_ptr::Ptr{Cvoid},
                name::Cstring, url::Cstring, payload::Ptr{Cvoid})

ミラーコールバック関数です。

この関数はリモート参照に対する +refs/*:refs/* という refspec と mirror フラグを設定します.

mirror_cb()

mirror_callback に対する C 関数ポインタです。

message(c::GitCommit, raw::Bool=false)

コミット c で行われた変更を説明するコミットメッセージを返します。raw が false だと、少しだけ "整った" メッセージ (最後の改行を削除したもの) を返します。raw が true だと、末尾の改行は削除されません。

merge_analysis(repo::GitRepo, anns::Vector{GitAnnotated}) -> analysis, preference

anns に含まれる注釈の付いたブランチ先端が指すブランチに対して解析を実行し、マージが可能な状況を計算します。例えば anns[1] が anns[2] の祖先なら、merge_analysis はファストフォワードのマージが可能であることを報告します。

analysis と preference という二つの値を返します。analysis が取り得る値は次の通りです:

• MERGE_ANALYSIS_NONE: anns の要素はマージできない。
• MERGE_ANALYSIS_NORMAL: 通常のマージが行える。HEAD およびユーザーがマージしようとしているコミットが全て共通の祖先から分岐している。この場合は変更を解決する必要があり、そのとき衝突が発生する可能性がある。
• MERGE_ANALYSIS_UP_TO_DATE: ユーザーがマージしようとしている入力のコミットは全て HEAD から到達できる。そのためマージを実行する必要はない。
• MERGE_ANALYSIS_FASTFORWARD: 入力のコミットは HEAD の子孫である。マージは必要なく、ユーザーはコミットを (全て) 直接チェックアウトできる。
• MERGE_ANALYSIS_UNBORN: レポジトリの HEAD が存在しないコミットを参照している。マージはできないが、入力のコミットをチェックアウトできる可能性はある。

preference が取り得る値もいくつかあります:

• MERGE_PREFERENCE_NONE: マージ方法に関してユーザーの指定はない。
• MERGE_PREFERENCE_NO_FASTFORWARD: ファストフォワードのマージを許可しない。
• MERGE_PREFERENCE_FASTFORWARD_ONLY: ファストフォワードのマージだけを許可する (衝突が起こる可能性のある他の種類のマージは許可しない)。

preference はレポジトリあるいはグローバルの git 設定から制御できます。

LibGit2.name(ref::GitReference)

ref の完全な名前を返します。

name(rmt::GitRemote)

"origin" のようなリモートレポジトリの名前を取得します。リモートが匿名だと名前は空文字列 "" となります (参照: GitRemoteAnon)。

例

julia> repo_url = "https://github.com/JuliaLang/Example.jl";

julia> repo = LibGit2.clone(cache_repo, "test_directory");

julia> remote = LibGit2.GitRemote(repo, "origin", repo_url);

julia> name(remote)
"origin"

LibGit2.name(tag::GitTag)

tag の名前を取得します ("v0.5" など)。

need_update(repo::GitRepo)

git update-index と等価です。repo で更新が必要なら true を返します。

objtype(obj_type::Consts.OBJECT)

列挙体の値に対応する型を返します。

LibGit2.path(repo::GitRepo)

レポジトリ repo のベースファイルパスを返します。

• 通常のレポジトリのベースファイルパスは通常 ".git" ディレクトリの親ディレクトリです (注意: これはワーキングディレクトリと異なる可能性があります。workdir を参照してください)。
• bare レポジトリのベースファイルパスは git 関連のファイルがあるディレクトリです。

gitdir, workdir も参照してください。

peel([T,] ref::GitReference)

型 T が得られるまで再帰的に ref の "皮をむき" ます。T が与えられなければ、GitTag 以外のオブジェクトが得られるまで ref の皮がむかれます。

• GitTag の皮をむくと、それが参照するオブジェクトになります。
• GitCommit の皮をむくと、GitTree になります。

peel([T,] obj::GitObject)

型 T が得られるまで再帰的に obj の "皮をむき" ます。T が与えられなければ、型が変わるまで皮がむかれます。

• GitTag の皮をむくと、それが参照するオブジェクトになります。
• GitCommit の皮をむくと、GitTree になります。

LibGit2.posixpath(path)

パスを表す文字列 path を POSIX 分離文字を使う形に標準化します。

push(rmt::GitRemote, refspecs; force::Bool=false, options::PushOptions=PushOptions())

指定されたリモート git レポジトリ rmt にプッシュします。プッシュ先のリモートブランチは refspecs で決定されます。キーワード引数は次の通りです:

• force: true だと、衝突を無視する強制的なプッシュを行う。
• options: プッシュのオプション。利用するプロキシヘッダーなど。詳細は PushOptions を参照。

push(repo::GitRepo; kwargs...)

repo の upstream に更新をプッシュします。

キーワード引数は次の通りです:

• remote::AbstractString="origin": プッシュ先の upstream リモートの名前。
• remoteurl::AbstractString="": remote の URL。
• refspecs=AbstractString[]: プッシュのプロパティ。
• force::Bool=false: プッシュが強制されたものであるかどうか。強制されたプッシュはリモートブランチを上書きする。
• credentials=nothing: プライベートな remote に対する認証で使う資格情報と設定。
• callbacks=Callbacks(): ユーザーが提供するコールバックとペイロード。

この関数は git push [<remoteurl>|<repo>] [<refspecs>] と等価です。

LibGit2.push!(w::GitRevWalker, cid::GitHash)

コミット cid から始まる走査を GitRevWalker 型の値 w にプッシュします。例えばこの関数を使うと、特定の年以降のコミット全てに関数を適用できます: その年の最初のコミットを cid としてこの関数に渡して、返り値の w を map に渡してください。

LibGit2.push_head!(w::GitRevWalker)

HEAD コミットとその祖先を GitRevWalker 型の値 w にプッシュします。この関数を呼ぶと、HEAD とその祖先全てが走査されることが保証されます。

push_refspecs(rmt::GitRemote) -> Vector{String}

指定されたリモート git レポジトリ rmt に対するプッシュ refspec を取得します。この refspec にはどのブランチにプッシュするかに関する情報が含まれます。

例

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, "upstream");

julia> LibGit2.add_push!(repo, remote, "refs/heads/master");

julia> close(remote);

julia> remote = LibGit2.get(LibGit2.GitRemote, repo, "upstream");

julia> LibGit2.push_refspecs(remote)
String["refs/heads/master"]

raw(id::GitHash) -> Vector{UInt8}

GitHash の生バイト列を長さ 20 のベクトルとして取得します。

LibGit2.read_tree!(idx::GitIndex, tree::GitTree)
LibGit2.read_tree!(idx::GitIndex, treehash::AbstractGitHash)

レポジトリに含まれるツリー tree (あるいは idx を保有するレポジトリ内の treehash が指すツリー) をインデックス idx に読み込みます。現在のインデックスの内容は置き換えられます。

LibGit2.rebase!(repo::GitRepo,
                upstream::AbstractString="",
                newbase::AbstractString="")

現在のブランチの自動的なマージリベースを試みます。リベース元には upstream が与えられればそれが使われ、与えられなければ upstream の追跡ブランチが使われます。newbase は rebase 先の ("onto" の) ブランチであり、デフォルトの値は upstream です。

衝突が起きて自動的に解決できない場合、リベースは中断されます。このときレポジトリとワーキングツリーは最初の状態に戻り、rebase! は GitError を送出します。この関数は次のコマンドライン文とほぼ同じです:

git rebase --merge [<upstream>]
if [ -d ".git/rebase-merge" ]; then
    git rebase --abort
fi

LibGit2.ref_list(repo::GitRepo) -> Vector{String}

git レポジトリ repo に含まれる全ての参照の名前からなるリストを取得します。

LibGit2.reftype(ref::GitReference) -> Cint

ref のタイプに対応する Cint を返します。返り値は次の通りです:

• 0: 参照が不当なとき。
• 1: 参照がオブジェクト ID のとき。
• 2: 参照がシンボリックのとき。

LibGit2.remotes(repo::GitRepo)

git レポジトリ repo のリモートの名前からなるベクトルを返します。

remove!(repo::GitRepo, files::AbstractString...)
remove!(idx::GitIndex, files::AbstractString...)

files で指定されるパスを持つファイルを、インデックス idx (または git レポジトリ repo のインデックス) から全て取り除きます。

reset(val::Integer, flag::Integer)

val の flag 番目のビットをアンセット (0 に設定) します。

reset!(payload, [config]) -> CredentialPayload

payload の状態を初期値にリセットし、資格情報コールバックでもう一度使えるようにします。configが与えられれば、設定もその値に更新されます。

reset!(repo::GitRepo, obj::Union{GitObject, Nothing}, pathspecs::AbstractString...)

目標のコミットツリーのインデックスにおいて、pathspecs が指定するエントリーを更新します。

reset!(repo::GitRepo, obj::GitObject, mode::Cint;
       checkout_opts::CheckoutOptions = CheckoutOptions())

現在のヘッドを指定されたコミット OID に設定し、オプションに応じてインデックスとワーキングツリーをそこにリセットします。

reset!(repo::GitRepo, committish::AbstractString, pathspecs::AbstractString...)

git reset [<committish>] [–] <pathspecs>... と等価です。

reset!(repo::GitRepo, id::GitHash, mode::Cint=Consts.RESET_MIXED)

git レポジトリ repo を id の状態にリセットします。リセットは mode が指定するモードで行われます。mode に指定できるのは次の三つのいずれかです:

1. Consts.RESET_SOFT: HEAD を id に移動する。
2. Consts.RESET_MIXED: HEAD を id に移動し、インデックスを id にリセットする (デフォルト)。
3. Consts.RESET_HARD: HEAD を id に移動し、インデックスを id にリセットし、ワーキングツリーの変更を全て破棄する。

例

# 変更のフェッチ
LibGit2.fetch(repo)
isfile(joinpath(repo_path, our_file)) # false が返る。

# ファストフォワードのマージで変更を取り込む。
LibGit2.merge!(repo, fastforward=true)

# 最初ファイルはローカルに存在しておらずリモートに存在していたので、
# ブランチをリセットする必要がある。
head_oid = LibGit2.head_oid(repo)
new_head = LibGit2.reset!(repo, head_oid, LibGit2.Consts.RESET_HARD)

この例は、フェッチするリモートが our_file というファイルを持つためにリセットが必要になる状況を想定しています。

この関数は git reset [--soft | --mixed | --hard] <id> と等価です。

例

repo = LibGit2.GitRepo(repo_path)
head_oid = LibGit2.head_oid(repo)
open(joinpath(repo_path, "file1"), "w") do f
    write(f, "111
")
end
LibGit2.add!(repo, "file1")
mode = LibGit2.Consts.RESET_HARD
# file1 への変更が破棄され、unstage される
new_head = LibGit2.reset!(repo, head_oid, mode)

restore(s::State, repo::GitRepo)

git レポジトリ repo を State 型の値で表される以前の状態 s に戻します (例えばマージを行う前のブランチの HEAD など)。s は snapshot 関数で生成できます。

LibGit2.revcount(repo::GitRepo, commit1::AbstractString, commit2::AbstractString)

commit1 と commit2 (文字列形式の committish OID) の間にあるリビジョンの個数を返します。commit1 と commit2 が異なるブランチにある可能性もあるので、revcount は "left-right" の形でリビジョンを集計します ──返り値は Int の二タプルであり、それぞれ "右の" コミットと "左の" コミットの個数、つまりそれぞれのコミットから到達可能なコミットからなる木の対称差における自分の側の要素数 (から 1 を引いた値) を表します。

この関数は git rev-list --left-right --count <commit1> <commit2> と等価です。

例

repo = LibGit2.GitRepo(repo_path)
repo_file = open(joinpath(repo_path, test_file), "a")
println(repo_file, "hello world")
flush(repo_file)
LibGit2.add!(repo, test_file)
commit_oid1 = LibGit2.commit(repo, "commit 1")
println(repo_file, "hello world again")
flush(repo_file)
LibGit2.add!(repo, test_file)
commit_oid2 = LibGit2.commit(repo, "commit 2")
LibGit2.revcount(repo, string(commit_oid1), string(commit_oid2))

これを実行すると (-1, 0) が返ります。

set_remote_url(repo::GitRepo, remote_name, url)
set_remote_url(repo::String, remote_name, url)

レポジトリ repo あるいは path にある git レポジトリの、remote_name に対するフェッチおよびプッシュ URL を url に設定します。git レポジトリは多くの場合 "origin" をリモート名として使います。

例

repo_path = joinpath(tempdir(), "Example")
repo = LibGit2.init(repo_path)
LibGit2.set_remote_url(repo, "upstream",
                       "https://github.com/JuliaLang/Example.jl")
LibGit2.set_remote_url(repo_path, "upstream2",
                       "https://github.com/JuliaLang/Example2.jl")

LibGit2.shortname(ref::GitReference)

ref の名前の "人間が読める" 形をした省略形を返します。

julia> repo = LibGit2.GitRepo(path_to_repo);

julia> branch_ref = LibGit2.head(repo);

julia> LibGit2.name(branch_ref)
"refs/heads/master"

julia> LibGit2.shortname(branch_ref)
"master"

snapshot(repo::GitRepo) -> State

git レポジトリ repo の現在状態のスナップショットを撮ります。スナップショットには現在の HEAD とインデックス、そしてコミットしていない全ての変更が保存されます。返り値の State に restore を呼び出すことで、スナップショットを撮った時点の状態にレポジトリを復元できます。

LibGit2.split_cfg_entry(ce::LibGit2.ConfigEntry)
    -> Tuple{String,String,String,String}

ConfigEntry をセクション・サブセクション・名前・値という部分に分けます。

例

次の git 設定ファイルが存在するとします:

[credential "https://example.com"]
    username = me

このとき ConfigEntry は次のようになります:

julia> entry
ConfigEntry("credential.https://example.com.username", "me")

julia> LibGit2.split_cfg_entry(entry)
("credential", "https://example.com", "username", "me")

詳細は git config syntax documentation を参照してください。

LibGit2.status(repo::GitRepo, path::String) -> Union{Cuint, Cvoid}

git レポジトリ repo のパス path に存在するファイルの状態を確認します。例えば path にあるファイルが変更されていてステージとコミットを必要とするかどうかの判定に利用できます。

stage(ie::IndexEntry) -> Cint

ie のステージ番号を取得します。ステージ番号 0 はワーキングツリーの現在の状態を表し、他の番号はマージの衝突が起こった場合に使われます。そのような場合には、ファイルの現在状態が衝突のどちら側に属するのかが IndexEntry のステージ番号によって表されます。ステージ番号 0 はマージを試みる前の状態であり、1 はローカルで行われた変更、2 以降は他のブランチで行われた変更を表します (例えば複数のブランチが絡む "タコ足" マージでは 2, 3, 4, ... のステージ番号が使われることになります)。

LibGit2.tag_create(repo::GitRepo, tag::AbstractString, commit; kwargs...)

git レポジトリ repo のコミット commit に新しいタグ tag を作成します (例えば "v0.5" など)。

キーワード引数は次の通りです:

• msg::AbstractString="": タグに対するメッセージ。
• force::Bool=false: true なら、既存の参照が上書きされる。
• sig::Signature=Signature(repo): タグ付けを行う人物の署名。

LibGit2.tag_delete(repo::GitRepo, tag::AbstractString)

git レポジトリ repo からタグ tag を削除します。

LibGit2.tag_list(repo::GitRepo) -> Vector{String}

git レポジトリ repo に含まれる全てのタグのリストを取得します。

LibGit2.target(tag::GitTag)

tag の目標オブジェクトの GitHash を返します。

toggle(val::Integer, flag::Integer)

val の flag 番目のビットを反転させます。つまり 0 は 1 になり、1 は 0 になります。

transact(f::Function, repo::GitRepo)

git レポジトリ repo に、snapshot でスナップショットを取得してから、f を適用します。f でエラーが起こると、repo は restore によって最初に撮ったスナップショットの状態に戻されます。発生したエラーは再度送出されますが、repo の状態が壊れることはありません。

treewalk(f, tree::GitTree, post::Bool=false)

tree およびその部分木の要素を、行きがけ順 (post order) あるいは帰りがけ順 (pre order) で走査します。行きがけ順とは木の頂点から始めて左に向かって再帰的に下り、その後は部分木を右に向かって訪れる順序を意味します。帰りがけ順とは一番左の部分木の一番下の要素から始まり、右の部分木 (の一番下) を順に訪れる (頂点が最後になる) 順序を意味します。

関数パラメータ f は次のシグネチャを持つべきです:

(String, GitTreeEntry) -> Cint

f が負の値を返すと木の走査が終了します。また post が false だと、f が正の値を返す要素より (右) 下の部分木に対する走査がスキップされます。

upstream(ref::GitReference) -> Union{GitReference, Nothing}

ref を持つブランチが指定された upstream ブランチを持つかどうかを判定します。

要求されたブランチが upstream に存在するなら upstream におけるブランチを指す GitReference を返し、存在しないなら nothing を返します。

update!(repo::GitRepo, files::AbstractString...)
update!(idx::GitIndex, files::AbstractString...)

インデックス idx (あるいはレポジトリ repo のインデックス) 内の files で指定されるパスを持つファイルを全て更新します。ディスクから削除されているファイルをインデックスから削除し、変更されているファイルに対するオブジェクトデータベース内のエントリーを更新することで、インデックス内の全てのファイルの状態をディスク上の状態と合わせます。

url(rmt::GitRemote)

リモート git レポジトリのフェッチ URL を取得します。

例

julia> repo_url = "https://github.com/JuliaLang/Example.jl";

julia> repo = LibGit2.init(mktempdir());

julia> remote = LibGit2.GitRemote(repo, "origin", repo_url);

julia> LibGit2.url(remote)
"https://github.com/JuliaLang/Example.jl"

version() -> VersionNumber

現在使用中の libgit2 のバージョンを VersionNumber として返します。

with(f::Function, obj)

リソース管理で使われるヘルパー関数です。f を obj に適用し、f が正常に値を返すかエラーを送出したら obj に対して close を呼びます。この関数を使うと、アロケートした git リソースが必要なくなると同時にファイナライズされることを保証できます。

with_warn(f::Function, ::Type{T}, args...)

リソース管理で使われるヘルパー関数です。args から型 T のインスタンスを構築し、それに f を適用します。f が正常に値を返すかエラーを送出したら、構築された T 型のオブジェクトに対して close を呼び出します。この関数を使うと、アロケートされた git リソースが必要なくなると同時にファイナライズされることを保証できます。f でエラーが発生すると、エラーを含む警告が表示されます。

LibGit2.workdir(repo::GitRepo)

git レポジトリ repo のワーキングディレクトリを返します。bare レポジトリではエラーとなります。

gitdir, path も参照してください。

(::Type{T})(te::GitTreeEntry) where T<:GitObject

te が参照する git オブジェクトを取得し、実際の型としてそれを返します。例えば GitBlob 型や GitTag 型の値が返ります。

例

tree = LibGit2.GitTree(repo, "HEAD^{tree}")
tree_entry = tree[1]
blob = LibGit2.GitBlob(tree_entry)

UserPasswordCredential <: AbstractCredential

パラメータに user と password だけをサポートする資格情報を表す型です。

SSHCredential <: AbstractCredential

SSH 資格情報を表す型です。

isfilled(cred::AbstractCredential) -> Bool

資格情報に対して、認証で使う準備ができていることを確認します。

CachedCredentials

資格情報を再利用のためにキャッシュするための型です。

LibGit2.CredentialPayload

資格情報コールバックを同じ URL に対して複数回呼び出すときに、その状態を保持するための型です。異なる URL に対して同じ CredentialPayload インスタンスを使うときは、そのインスタンスに対して reset! を行う必要があります。

approve(payload::CredentialPayload; shred::Bool=true) -> Nothing

資格情報 payload を以降の認証で再利用するために保存します。認証が成功したときにだけ呼び出されるべきです。

キーワード引数 shred は資格情報のペイロードに含まれるセンシティブな情報を破壊すべきかどうかを制御します。テスト中にだけ false にするべきです。

reject(payload::CredentialPayload; shred::Bool=true) -> Nothing

資格情報の payload を破棄して、将来の認証で使えないようにします。認証が成功しなかったときにだけ呼び出されるべきです。

キーワード引数 shred は資格情報のペイロードに含まれるセンシティブな情報を破壊すべきかどうかを制御します。テスト中にだけ false にするべきです。