LibGit2

LibGit2.Buffer

Буфер данных для экспорта данных из libgit2. Соответствует структуре git_buf.

При получении данных из LibGit2 типичное использование будет выглядеть следующим образом:

buf_ref = Ref(Buffer())
@check ccall(..., (Ptr{Buffer},), buf_ref)
# операция над buf_ref
free(buf_ref)

В частности, обратите внимание, что LibGit2.free должен быть вызван после этого на объекте Ref.

LibGit2.CheckoutOptions

Соответствует структуре git_checkout_options.

Поля представляют собой:

• version: версия используемой структуры, на случай, если это изменится позже. На данный момент всегда 1.
• checkout_strategy: определяет, как обрабатывать конфликты и следует ли принудительно выполнять checkout/воссоздавать отсутствующие файлы.
• disable_filters: если ненулевое, не применять фильтры, такие как CLRF (для преобразования перевода строк файлов между UNIX и DOS).
• dir_mode: режим чтения/записи/доступа для любых каталогов, участвующих в checkout. По умолчанию 0755.
• file_mode: режим чтения/записи/доступа для любых файлов, участвующих в checkout. По умолчанию 0755 или 0644, в зависимости от блоба.
• file_open_flags: битовые флаги, используемые для открытия любых файлов во время checkout.
• notify_flags: Флаги для того, о каких конфликтах пользователь должен быть уведомлен.
• notify_cb: Необязательная функция обратного вызова для уведомления пользователя, если возникает конфликт при checkout. Если эта функция возвращает ненулевое значение, checkout будет отменен.
• notify_payload: Полезная нагрузка для функции обратного вызова уведомления.
• progress_cb: Необязательная функция обратного вызова для отображения прогресса checkout.
• progress_payload: Полезная нагрузка для функции обратного вызова прогресса.
• paths: Если не пусто, описывает, какие пути искать во время checkout. Если пусто, checkout будет выполнен для всех файлов в репозитории.
• baseline: Ожидаемое содержимое workdir, зафиксированное в (указателе на) GitTree. По умолчанию соответствует состоянию дерева на HEAD.
• baseline_index: Ожидаемое содержимое workdir, зафиксированное в (указателе на) GitIndex. По умолчанию соответствует состоянию индекса на HEAD.
• target_directory: Если не пусто, выполнить checkout в этот каталог вместо workdir.
• ancestor_label: В случае конфликтов, имя стороны общего предка.
• our_label: В случае конфликтов, имя "нашей" стороны.
• their_label: В случае конфликтов, имя "их" стороны.
• perfdata_cb: Необязательная функция обратного вызова для отображения данных о производительности.
• perfdata_payload: Полезная нагрузка для функции обратного вызова производительности.

LibGit2.CloneOptions

Соответствует структуре git_clone_options.

Поля представляют собой:

• version: версия используемой структуры, на случай, если это изменится позже. На данный момент всегда 1.
• checkout_opts: Опции для выполнения проверки удаленного репозитория в рамках клонирования.
• fetch_opts: Опции для выполнения предварительного получения удаленного репозитория в рамках клонирования.
• bare: Если 0, клонировать полный удаленный репозиторий. Если ненулевое значение, выполнить "bare" клон, в котором нет локальной копии исходных файлов в репозитории, и gitdir и workdir совпадают.
• localclone: Флаг, указывающий, следует ли клонировать локальную базу данных объектов или выполнять получение. По умолчанию позволяет git решать. Он не будет использовать git-осведомленный транспорт для локального клона, но будет использовать его для URL, начинающихся с file://.
• 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, чтобы описать коммит. По умолчанию 10 (так что будут проверены 10 самых последних тегов, чтобы увидеть, описывают ли они коммит).
• describe_strategy: следует ли учитывать все записи в refs/tags (эквивалентно git-describe --tags) или все записи в refs/ (эквивалентно git-describe --all). По умолчанию отображаются только аннотированные теги. Если передан Consts.DESCRIBE_TAGS, будут учитываться все теги, аннотированные или нет. Если передан Consts.DESCRIBE_ALL, будет учитываться любой реф в refs/.
• 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: Флаги для дельты и объектов с каждой стороны. Определяет, следует ли рассматривать файл(ы) как бинарные/текстовые, существуют ли они с каждой стороны диффа и известны ли идентификаторы объектов как корректные.
• similarity: Используется для указания, был ли файл переименован или скопирован.
• nfiles: Количество файлов в дельте (например, если дельта была выполнена на идентификаторе коммита подмодуля, она может содержать более одного файла).
• old_file: DiffFile, содержащий информацию о файле(ах) до изменений.
• new_file: DiffFile, содержащий информацию о файле(ах) после изменений.

LibGit2.DiffFile

Описание одной стороны дельты. Соответствует структуре git_diff_file.

Поля представляют:

• id: GitHash элемента в диффе. Если элемент пуст на этой стороне диффа (например, если дифф касается удаления файла), это будет GitHash(0).
• path: путь, заканчивающийся на NULL, к элементу относительно рабочего каталога репозитория.
• size: размер элемента в байтах.
• flags: комбинация флагов git_diff_flag_t. i-й бит этого целого числа устанавливает i-й флаг.
• mode: режим stat для элемента.
• id_abbrev: присутствует только в версиях LibGit2, равных или более новых, чем 0.25.0. Длина поля id, когда оно преобразовано с помощью string. Обычно равно OID_HEXSZ (40).

LibGit2.DiffOptionsStruct

Соответствует структуре git_diff_options.

Поля представляют собой:

• version: версия используемой структуры, на случай, если она изменится позже. На данный момент всегда 1.
• flags: флаги, контролирующие, какие файлы будут отображаться в диффе. По умолчанию DIFF_NORMAL.
• ignore_submodules: следует ли учитывать файлы в подмодулях или нет. По умолчанию SUBMODULE_IGNORE_UNSPECIFIED, что означает, что конфигурация подмодуля будет контролировать, будет ли он отображаться в диффе или нет.
• pathspec: путь к файлам, которые следует включить в дифф. По умолчанию используются все файлы в репозитории.
• notify_cb: необязательный обратный вызов, который уведомит пользователя об изменениях в диффе по мере добавления дельт файлов.
• progress_cb: необязательный обратный вызов, который будет отображать прогресс диффа. Актуально только для версий libgit2 не ниже 0.24.0.
• payload: полезная нагрузка, передаваемая в notify_cb и progress_cb.
• context_lines: количество неизмененных строк, используемых для определения границ хунка. Это также количество строк, которые будут показаны до/после хунка для предоставления контекста. По умолчанию 3.
• interhunk_lines: максимальное количество неизмененных строк между двумя отдельными хунками, разрешенное перед объединением хунков. По умолчанию 0.
• id_abbrev: устанавливает длину сокращенного GitHash для печати. По умолчанию 7.
• max_size: максимальный размер файла блоба. Выше этого размера он будет рассматриваться как бинарный блоб. По умолчанию 512 МБ.
• old_prefix: виртуальный каталог файлов, в который помещаются старые файлы с одной стороны диффа. По умолчанию "a".
• new_prefix: виртуальный каталог файлов, в который помещаются новые файлы с одной стороны диффа. По умолчанию "b".

LibGit2.FetchHead

Содержит информацию о HEAD во время извлечения, включая имя и URL ветки, из которой было извлечено, oid HEAD и информацию о том, был ли извлеченный HEAD объединен локально.

Поля представляют собой:

• name: Имя в локальной базе данных ссылок извлечения, например, "refs/heads/master".
• url: URL извлеченного HEAD.
• oid: GitHash конца извлеченного HEAD.
• ismerge: Булевый флаг, указывающий, были ли изменения на удаленном сервере объединены с локальной копией или нет. Если true, локальная копия актуальна по сравнению с удаленным извлеченным HEAD.

LibGit2.FetchOptions

Соответствует структуре git_fetch_options.

Поля представляют собой:

• version: версия используемой структуры, на случай, если она изменится позже. На данный момент всегда 1.
• callbacks: удаленные обратные вызовы, которые следует использовать во время извлечения.
• prune: следует ли выполнять очистку после извлечения или нет. По умолчанию используется настройка из GitConfig.
• update_fetchhead: следует ли обновлять FetchHead после извлечения. По умолчанию выполняется обновление, что является нормальным поведением git.
• download_tags: следует ли загружать теги, присутствующие на удаленном сервере, или нет. По умолчанию запрашиваются теги для объектов, которые все равно загружаются с сервера.
• proxy_opts: параметры для подключения к удаленному серверу через прокси. См. ProxyOptions. Присутствует только в версиях libgit2, более новых или равных 0.25.0.
• custom_headers: любые дополнительные заголовки, необходимые для извлечения. Присутствует только в версиях libgit2, более новых или равных 0.24.0.

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

Аннотированное git-сообщение содержит информацию о том, как оно было найдено и почему, так что операции rebase или merge имеют больше информации о контексте коммита. Файлы конфликтов содержат информацию о конфликтующих исходных/целевых ветках в слиянии, например. Аннотированный коммит может ссылаться на вершину удаленной ветки, например, когда передан FetchHead, или на голову ветки, описанную с помощью GitReference.

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

Создайте объект GitBlame для файла по пути path, используя информацию о изменениях, полученную из истории repo. Объект GitBlame фиксирует, кто изменил какие части файла, когда и как. Параметр options управляет тем, как разделять содержимое файла и какие коммиты исследовать - смотрите BlameOptions для получения дополнительной информации.

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

Возвращает объект GitBlob из repo, указанный hash/spec.

• hash — это полный (GitHash) или частичный (GitShortHash) хеш.
• spec — это текстовая спецификация: см. документацию git для полного списка.

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

Возвращает объект GitCommit из repo, указанный hash/spec.

• hash — это полный (GitHash) или частичный (GitShortHash) хеш.
• spec — это текстовая спецификация: см. документацию git для полного списка.

GitConfig(path::AbstractString, level::Consts.GIT_CONFIG=Consts.CONFIG_LEVEL_APP, force::Bool=false)

Создайте новый GitConfig, загрузив информацию о конфигурации из файла по пути path. См. addfile для получения дополнительной информации о параметрах level, repo и force.

GitConfig(repo::GitRepo)

Получите сохраненную конфигурацию для репозитория git repo. Если у repo нет установленного конкретного файла конфигурации, будет использована конфигурация git по умолчанию.

GitConfig(level::Consts.GIT_CONFIG=Consts.CONFIG_LEVEL_DEFAULT)

Получите конфигурацию git по умолчанию, загрузив глобальные и системные файлы конфигурации в приоритетную конфигурацию. Это можно использовать для доступа к параметрам конфигурации по умолчанию вне конкретного репозитория git.

GitHash

Идентификатор объекта git, основанный на хеше sha-1. Это строка длиной 20 байт (40 шестнадцатеричных цифр), используемая для идентификации GitObject в репозитории.

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

Верните указанный объект (GitCommit, GitBlob, GitTree или GitTag) из repo, указанный hash/spec.

• hash — это полный (GitHash) или частичный (GitShortHash) хеш.
• spec — это текстовая спецификация: смотрите документацию git для полного списка.

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

Ищите удаленный git-репозиторий по его имени и URL. Использует рефспецификацию по умолчанию для получения.

Примеры

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

Ищите удаленный git-репозиторий, используя только его URL, а не его имя.

Примеры

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

LibGit2.GitRepo(path::AbstractString)

Открыть git-репозиторий по адресу path.

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

Открыть git-репозиторий по path с расширенными параметрами управления (например, если текущий пользователь должен быть членом специальной группы доступа для чтения path).

GitRevWalker(repo::GitRepo)

GitRevWalker проходит через ревизии (т.е. коммиты) git-репозитория repo. Это коллекция коммитов в репозитории, и она поддерживает итерацию и вызовы к LibGit2.map и LibGit2.count (например, LibGit2.count можно использовать для определения, какой процент коммитов в репозитории был сделан определенным автором).

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

Здесь LibGit2.count находит количество коммитов вдоль прохода с определенным GitHash. Поскольку GitHash уникален для коммита, cnt будет равен 1.

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

Сокращенный идентификатор объекта git, который можно использовать для идентификации объекта git, когда он уникален, состоящий из первых len шестнадцатеричных цифр hash (оставшиеся цифры игнорируются).

LibGit2.GitSignature

Это обертка Julia вокруг указателя на объект git_signature.

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

Соберите информацию о статусе каждого файла в репозитории git repo (например, изменен ли файл, добавлен в индекс и т.д.). status_opts можно использовать для установки различных параметров, например, следует ли учитывать неотслеживаемые файлы или включать подмодули. См. StatusOptions для получения дополнительной информации.

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

Возвращает объект GitTag из repo, указанный hash/spec.

• hash — это полный (GitHash) или частичный (GitShortHash) хеш.
• spec — это текстовая спецификация: см. документацию git для полного списка.

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

Возвращает объект GitTree из repo, указанный hash/spec.

• 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: GitHash самого нового коммита, с которого следует смотреть изменения.
• oldest_commit: 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 в индекс, полученный в результате слияния.
  • MERGE_NO_RECURSIVE: если сливаемые коммиты имеют несколько баз слияния, использовать первую, а не пытаться рекурсивно объединить базы.

• rename_threshold: насколько похожи два файла, чтобы считать один переименованием другого. Это целое число, которое устанавливает процентное сходство. По умолчанию 50.

• target_limit: максимальное количество файлов для сравнения с целью поиска переименований. По умолчанию 200.

• metric: необязательная пользовательская функция, используемая для определения сходства между двумя файлами для обнаружения переименований.

• recursion_limit: верхний предел на количество слияний общих предков, которые необходимо выполнить, чтобы попытаться создать новую виртуальную базу слияния для слияния. По умолчанию нет предела. Это поле присутствует только в версиях libgit2 новее 0.24.0.

• default_driver: драйвер слияния, который следует использовать, если обе стороны изменены. Это поле присутствует только в версиях libgit2 новее 0.25.0.

• 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: enum для типа прокси, который следует использовать. Определен в git_proxy_t. Соответствующий Julia enum - 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: актуально только если версия LibGit2 больше или равна 0.25.0. Устанавливает параметры для использования прокси для связи с удаленным сервером. См. ProxyOptions для получения дополнительной информации.
• custom_headers: актуально только если версия LibGit2 больше или равна 0.24.0. Дополнительные заголовки, необходимые для операции отправки.

LibGit2.RebaseOperation

Описывает одну инструкцию/операцию, которая должна быть выполнена во время ребейза. Соответствует структуре git_rebase_operation.

Поля представляют:

• optype: тип операции ребейза, которая в настоящее время выполняется. Варианты:

  • REBASE_OPERATION_PICK: выбрать коммит, о котором идет речь.
  • REBASE_OPERATION_REWORD: выбрать коммит, о котором идет речь, но переписать его сообщение с помощью подсказки.
  • REBASE_OPERATION_EDIT: выбрать коммит, о котором идет речь, но позволить пользователю редактировать содержимое коммита и его сообщение.
  • REBASE_OPERATION_SQUASH: объединить коммит, о котором идет речь, с предыдущим коммитом. Сообщения коммитов будут объединены.
  • REBASE_OPERATION_FIXUP: объединить коммит, о котором идет речь, с предыдущим коммитом. Будет использовано только сообщение предыдущего коммита.
  • REBASE_OPERATION_EXEC: не выбирать коммит. Выполнить команду и продолжить, если команда завершится успешно.

• id: GitHash коммита, над которым ведется работа на этом этапе ребейза.

• exec: в случае использования REBASE_OPERATION_EXEC команда, которую нужно выполнить на этом этапе (например, запуск тестового набора после каждого коммита).

LibGit2.RebaseOptions

Соответствует структуре git_rebase_options.

Поля представляют собой:

• version: версия используемой структуры, на случай, если это изменится позже. На данный момент всегда 1.
• quiet: информировать другие git-клиенты, помогающие с/работающие над ребейзом, что ребейз должен быть выполнен "тихо". Используется для совместимости. По умолчанию 1.
• inmemory: начать ребейз в памяти. Вызывающие функции, работающие над ребейзом, могут проходить через его этапы и фиксировать любые изменения, но не могут перематывать HEAD или обновлять репозиторий. workdir не будет изменен. Присутствует только в версиях libgit2, более новых или равных 0.24.0.
• rewrite_notes_ref: имя ссылки на заметки, которые будут использоваться для переписывания заметок коммита по завершении ребейза.
• merge_opts: параметры слияния, контролирующие, как деревья будут объединяться на каждом этапе ребейза. Присутствует только в версиях libgit2, более новых или равных 0.24.0.
• checkout_opts: параметры проверки для записи файлов при инициализации ребейза, прохождении через него и его отмене. См. CheckoutOptions для получения дополнительной информации.

LibGit2.RemoteCallbacks

Настройки обратных вызовов. Соответствует структуре git_remote_callbacks.

LibGit2.SignatureStruct

Подпись действия (например, для коммитеров, теггеров и т. д.). Соответствует структуре git_signature.

Поля представляют собой:

• name: Полное имя коммитера или автора коммита.
• email: Электронная почта, по которой можно связаться с коммитером/автором.
• when: структура TimeStruct, указывающая, когда коммит был создан/закоммичен в репозиторий.

LibGit2.StatusEntry

Предоставляет различия между файлом, как он существует в HEAD, и индексом, а также предоставляет различия между индексом и рабочим каталогом. Соответствует структуре git_status_entry.

Поля представляют:

• status: содержит флаги состояния для файла, указывая, является ли он актуальным или был изменен каким-либо образом в индексе или рабочем дереве.
• head_to_index: указатель на DiffDelta, который инкапсулирует различия между файлом, как он существует в HEAD, и в индексе.
• index_to_workdir: указатель на DiffDelta, который инкапсулирует различия между файлом, как он существует в индексе, и в workdir.

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.

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)

В частности, обратите внимание, что LibGit2.free следует вызывать после этого на объекте Ref.

Напротив, при передаче вектора строк в LibGit2 обычно проще полагаться на неявное преобразование:

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

Обратите внимание, что вызов free не требуется, так как данные выделяются Julia.

LibGit2.TimeStruct

Время в подписи. Соответствует структуре git_time.

addfile(cfg::GitConfig, path::AbstractString,
        level::Consts.GIT_CONFIG=Consts.CONFIG_LEVEL_APP,
        repo::Union{GitRepo, Nothing} = nothing,
        force::Bool=false)

Добавляет существующий файл конфигурации git, расположенный по пути path, в текущий GitConfig cfg. Если файл не существует, он будет создан.

• level устанавливает уровень приоритета конфигурации git и определяется

Consts.GIT_CONFIG.

• repo является необязательным репозиторием, чтобы разрешить парсинг условных включений.
• Если force равно false и конфигурация для данного уровня приоритета уже существует,

addfile вызовет ошибку. Если force равно true, существующая конфигурация будет заменена на ту, что в файле по пути path.

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, см. ниже). Если файл был проигнорирован (в .gitignore или в конфигурации), он не будет добавлен, если только он уже не отслеживается в индексе, в этом случае он будет обновлен. Ключевой аргумент 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)

Добавляет fetch refspec для указанного rmt. Этот 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)

Добавляет push refspec для указанного rmt. Этот 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 и добавляет его в объектную базу данных repo как отдельный блоб. Возвращает 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)

Возвращает Signature автора коммита c. Автор — это человек, который внес изменения в соответствующий(ие) файл(ы). См. также committer.

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

Возвращает всех авторов коммитов в репозитории repo.

Примеры

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 в репозитории repo. commit — это GitHash, в строковом формате, который будет началом новой ветки. Если commit — это пустая строка, будет использован текущий HEAD.

Ключевые аргументы:

• track::AbstractString="": имя удаленной ветки, которую должна отслеживать эта новая ветка, если такая есть. Если пусто (по умолчанию), удаленная ветка отслеживаться не будет.
• force::Bool=false: если true, создание ветки будет принудительным.
• set_head::Bool=true: если true, после завершения создания ветки голова ветки будет установлена как HEAD репозитория repo.

Эквивалентно 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>. Выполняет checkout git-коммита commit (в виде строки GitHash) в repo. Если force равно true, принудительно выполняет checkout и отменяет все текущие изменения. Обратите внимание, что это отсоединяет текущий HEAD.

Примеры

repo = LibGit2.GitRepo(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 (который может быть удаленным 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_url, в локальное файловое хранилище по пути repo_path.

Ключевые аргументы:

• branch::AbstractString="": какую ветку удаленного репозитория клонировать, если не ветку по умолчанию (обычно master).
• isbare::Bool=false: если true, клонировать удаленный репозиторий как "bare", что сделает repo_path самой git-директория вместо repo_path/.git. Это означает, что рабочее дерево не может быть проверено. Играет роль аргумента командной строки git --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. Создает коммит в репозитории repo. msg — это сообщение коммита. Возвращает OID нового коммита.

Ключевые аргументы:

• refname::AbstractString=Consts.HEAD_FILE: если не NULL, имя ссылки, которую нужно обновить, чтобы она указывала на новый коммит. Например, "HEAD" обновит HEAD текущей ветки. Если ссылка еще не существует, она будет создана.
• author::Signature = Signature(repo) — это Signature, содержащая информацию о человеке, который авторизовал коммит.
• committer::Signature = Signature(repo) — это Signature, содержащая информацию о человеке, который закоммитил коммит в репозиторий. Не обязательно тот же, что и author, например, если author отправил патч committer, который его закоммитил.
• tree_id::GitHash = GitHash() — это git-дерево, которое будет использовано для создания коммита, показывающее его предков и связь с любой другой историей. tree должно принадлежать repo.
• parent_ids::Vector{GitHash}=GitHash[] — это список коммитов по GitHash, которые будут использоваться в качестве родительских коммитов для нового, и может быть пустым. Коммит может иметь несколько родителей, если это коммит слияния, например.

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

Зафиксируйте текущий патч в ребейзе rb, используя sig в качестве автора коммита. Не выдает сообщений, если коммит уже был применен.

committer(c::GitCommit)

Возвращает Signature коммитера коммита c. Коммитер — это человек, который изначально зафиксировал изменения, автором которых является author, но это не обязательно тот же человек, что и author, например, если author отправил патч коммитеру, который его зафиксировал.

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

Используя GitRevWalker walker для "прогулки" по каждому коммиту в истории репозитория, найдите количество коммитов, которые возвращают true, когда к ним применяется f. Ключевые аргументы: * 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
    LibGit2.count((oid, repo)->(oid == commit_oid1), walker, oid=commit_oid1, by=LibGit2.Consts.SORT_TIME)
end

LibGit2.count находит количество коммитов вдоль прогулки с определенным GitHash commit_oid1, начиная прогулку с этого коммита и двигаясь вперед во времени от него. Поскольку GitHash уникален для коммита, cnt будет равен 1.

counthunks(blame::GitBlame)

Возвращает количество различных "хунков" с файлом. Хунк может содержать несколько строк. Хунк обычно представляет собой часть файла, которая была добавлена/изменена/удалена вместе, например, функция, добавленная в исходный файл, или внутренний цикл, который был оптимизирован из этой функции позже.

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

Создайте новую ветку в репозитории repo с именем bname, которая указывает на коммит commit_obj (который должен быть частью repo). Если force равно true, перезапишите существующую ветку с именем bname, если она существует. Если force равно false и ветка с именем bname уже существует, эта функция вызовет ошибку.

credential_callback(...) -> Cint

Функция обратного вызова учетных данных LibGit2, которая предоставляет различные функции получения учетных данных в зависимости от протокола соединения. Указатель payload_ptr должен содержать объект LibGit2.CredentialPayload, который будет отслеживать состояние и настройки.

allowed_types содержит битовую маску значений LibGit2.Consts.GIT_CREDTYPE, указывающую, какие методы аутентификации следует пытаться использовать.

Аутентификация учетных данных выполняется в следующем порядке (если поддерживается):

• SSH-агент
• Пара SSH-ключей (приватный/публичный)
• Имя пользователя/пароль в открытом виде

Если пользователю будет предложено ввести учетные данные, он может прервать запрос, нажав ^D (нажимая клавишу управления вместе с клавишей d).

Примечание: Из-за особенностей процедуры аутентификации libgit2, когда аутентификация не удалась, эта функция вызывается снова без каких-либо указаний на то, была ли аутентификация успешной или нет. Чтобы избежать бесконечного цикла из-за повторного использования одних и тех же ошибочных учетных данных, мы будем отслеживать состояние с помощью полезной нагрузки.

Для получения дополнительных сведений см. руководство LibGit2 по аутентификации на сервере.

Указатель на функцию C для credentials_callback

Вернуть объект подписи. Освободите его после использования.

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}=Set([Consts.DELTA_ADDED, Consts.DELTA_MODIFIED, Consts.DELTA_DELETED])), и он устанавливает параметры для диффа. По умолчанию показываются файлы, добавленные, измененные или удаленные.

Возвращает только имена файлов, которые изменились, а не их содержимое.

Примеры

LibGit2.branch!(repo, "branch/a")
LibGit2.branch!(repo, "branch/b")
# добавляем файл в репозиторий
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)

Возвращает GitHash объекта, на который ссылается te.

entrytype(te::GitTreeEntry)

Возвращает тип объекта, на который ссылается te. Результат будет одним из типов, которые возвращает objtype, например, GitTree или GitBlob.

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

Получите из указанного удаленного git-репозитория rmt, используя refspecs для определения, какие удаленные ветки загружать. Ключевые аргументы:

• options: определяет параметры для загрузки, например, следует ли обрезать после этого. См. FetchOptions для получения дополнительной информации.
• msg: сообщение для вставки в рефлоги.

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

Получает обновления из upstream репозитория repo.

Ключевые аргументы:

• remote::AbstractString="origin": какой удаленный репозиторий, указанный по имени, использовать для получения данных из repo. Если это поле пустое, будет использован URL для создания анонимного удаленного репозитория.
• remoteurl::AbstractString="": URL remote. Если не указано, будет предполагаться на основе данного имени remote.
• refspecs=AbstractString[]: определяет свойства получения данных.
• credentials=nothing: предоставляет учетные данные и/или настройки при аутентификации против частного remote.
• callbacks=Callbacks(): пользовательские обратные вызовы и полезные нагрузки.

Эквивалентно git fetch [<remoteurl>|<repo>] [<refspecs>].

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

Возвращает список всех fetch heads для 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}

Получите fetch референсные спецификации для указанного rmt. Эти референсные спецификации содержат информацию о том, какие ветки загружать.

Примеры

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/*"]

Указатель функции C для fetchhead_foreach_callback

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

Найдите базу слияния (общего предка) между коммитами one и two. one и two могут быть в строковом формате. Верните GitHash базы слияния.

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

Выполните слияние git в репозитории repo, объединяя коммиты с расходящейся историей в текущую ветку. Верните true, если слияние прошло успешно, false в противном случае.

Ключевые аргументы:

• committish::AbstractString="": Объедините указанные коммиты в committish.
• branch::AbstractString="": Объедините ветку branch и все ее коммиты с тех пор, как она разошлась с текущей веткой.
• fastforward::Bool=false: Если fastforward равно true, объединяйте только в том случае, если слияние является быстрым (голова текущей ветки является предком коммитов, которые нужно объединить), в противном случае откажитесь от слияния и верните false. Это эквивалентно опции CLI git --ff-only.
• merge_opts::MergeOptions=MergeOptions(): merge_opts указывает параметры для слияния, такие как стратегия слияния в случае конфликтов.
• checkout_opts::CheckoutOptions=CheckoutOptions(): checkout_opts указывает параметры для шага проверки.

Эквивалентно git merge [--ff-only] [<committish> | <branch>].

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

Слияние изменений из аннотированных коммитов (захваченных как GitAnnotated объекты) anns в HEAD репозитория repo. Ключевые аргументы:

• merge_opts::MergeOptions = MergeOptions(): параметры для выполнения слияния, включая разрешение на fastforward. См. MergeOptions для получения дополнительной информации.
• checkout_opts::CheckoutOptions = CheckoutOptions(): параметры для выполнения checkout. См. 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 в HEAD репозитория repo. Если 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 (например, если изменения извлекаются из удаленной ветки, которая просто опережает локальный конец ветки).

LibGit2.fullname(ref::GitReference)

Вернуть имя ссылки, на которую указывает символическая ссылка ref. Если ref не является символической ссылкой, вернуть пустую строку.

features()

Возвращает список функций git, которые поддерживает текущая версия libgit2, такие как многопоточность или использование HTTPS или SSH.

filename(te::GitTreeEntry)

Возвращает имя файла объекта на диске, на который ссылается te.

filemode(te::GitTreeEntry) -> Cint

Возвращает UNIX filemode объекта на диске, на который ссылается te, в виде целого числа.

LibGit2.gitdir(repo::GitRepo)

Возвращает местоположение файлов "git" репозитория repo:

• для обычных репозиториев это местоположение папки .git.
• для голых репозиториев это местоположение самого репозитория.

См. также workdir, path.

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

Создайте строку на основе предоставленных компонентов URL. Когда ключевое слово scheme не указано, сгенерированный URL будет использовать альтернативный scp-подобный синтаксис.

Ключевые слова

• scheme::AbstractString="": схема URL, которая определяет используемый протокол. Для HTTP используйте "http", для SSH используйте "ssh" и т.д. Когда scheme не указано, формат вывода будет "ssh", но с использованием scp-подобного синтаксиса.
• username::AbstractString="": имя пользователя, которое будет использоваться в выводе, если указано.
• password::AbstractString="": пароль, который будет использоваться в выводе, если указан.
• host::AbstractString="": имя хоста, которое будет использоваться в выводе. Имя хоста обязательно должно быть указано.
• port::Union{AbstractString,Integer}="": номер порта, который будет использоваться в выводе, если указан. Не может быть указан при использовании scp-подобного синтаксиса.
• path::AbstractString="": путь, который будет использоваться в выводе, если указан.

!!! предупреждение Избегайте использования паролей в URL. В отличие от объектов учетных данных, Julia не может безопасно обнулить или уничтожить конфиденциальные данные после использования, и пароль может остаться в памяти; возможно, он будет раскрыт неинициализированной памятью.

Примеры

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 hash из данной строки, возвращая GitShortHash, если строка короче 40 шестнадцатеричных цифр, в противном случае GitHash.

Примеры

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

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

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

Возвращает GitReference для текущего HEAD репозитория repo.

head(pkg::AbstractString) -> String

Возвращает текущий HEAD GitHash репозитория pkg в виде строки.

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

Установите HEAD репозитория repo на объект, на который указывает ref.

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

Получите идентификатор объекта текущего HEAD git-репозитория repo.

LibGit2.headname(repo::GitRepo)

Получите имя текущего HEAD git-репозитория repo. Если repo в данный момент отсоединен, верните имя 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

Возвращает true, если a, GitHash в строковом формате, является предком b, GitHash в строковом формате.

Примеры

julia> repo = 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

Проверьте, находится ли коммит id (который является GitHash в строковом формате) в репозитории.

Примеры

julia> repo = 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 — это спецификации для опций для диффа.

Примеры

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdiff(repo, "HEAD") # должно быть false
open(joinpath(repo_path, new_file), "a") do f
    println(f, "вот мой классный новый файл")
end
LibGit2.isdiff(repo, "HEAD") # теперь true

Эквивалентно git diff-index <treeish> [-- <pathspecs>].

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

Проверьте, были ли изменения в отслеживаемых файлах в рабочем дереве (если cached=false) или в индексе (если cached=true). pathspecs — это спецификации для параметров для диффа.

Примеры

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdirty(repo) # должно быть false
open(joinpath(repo_path, new_file), "a") do f
    println(f, "вот мой классный новый файл")
end
LibGit2.isdirty(repo) # теперь true
LibGit2.isdirty(repo, new_file) # теперь true

Эквивалентно git diff-index HEAD [-- <pathspecs>].

LibGit2.isorphan(repo::GitRepo)

Проверьте, является ли текущая ветка "сиротой", т.е. не имеет коммитов. Первый коммит в этой ветке не будет иметь родителей.

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, в репозитории repo. Если remote равно true, repo предполагается как удаленный git-репозиторий. В противном случае он является частью локальной файловой системы.

Верните либо 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: Диапазон GitHash в формате oid1..oid2. 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

Здесь LibGit2.map посещает каждый коммит, используя GitRevWalker, и находит его GitHash.

Функция устанавливает +refs/*:refs/* референсные спецификации и флаг mirror для удаленной ссылки.

Указатель функции C для mirror_callback

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

Возвращает сообщение коммита, описывающее изменения, внесенные в коммит c. Если raw равно false, возвращается немного "очищенное" сообщение (в котором удалены любые ведущие переносы строк). Если raw равно true, сообщение не очищается от таких переносов строк.

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

Запустите анализ на ветках, на которые указывают аннотированные концы веток anns, и определите, при каких обстоятельствах их можно объединить. Например, если anns[1] является просто предком ann[2], то merge_analysis сообщит, что возможен быстрый переход (fast-forward) при слиянии.

Возвращает два вывода: 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: не разрешать никаких быстрых переходов (fast-forward) при слиянии. * MERGE_PREFERENCE_FASTFORWARD_ONLY: разрешать только быстрые переходы (fast-forward) и никакие другие типы (что может привести к конфликтам). 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. Возвращает true, если repo нуждается в обновлении.

objtype(obj_type::Consts.OBJECT)

Вернуть тип, соответствующий значению перечисления.

LibGit2.path(repo::GitRepo)

Возвращает базовый путь к файлу репозитория repo.

• для обычных репозиториев это обычно родительский каталог директории ".git" (заметьте: это может отличаться от рабочего каталога, смотрите workdir для получения дополнительных сведений).
• для голых репозиториев это местоположение "git" файлов.

Смотрите также gitdir, workdir.

peel([T,] ref::GitReference)

Рекурсивно снимает ref до тех пор, пока не будет получен объект типа T. Если T не предоставлен, то ref будет снят до тех пор, пока не будет получен объект, отличный от GitTag.

• GitTag будет снят до объекта, на который он ссылается.
• GitCommit будет снят до GitTree.

peel([T,] obj::GitObject)

Рекурсивно снимает obj, пока не будет получен объект типа T. Если T не предоставлен, то obj будет снят до изменения типа.

• 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...)

Отправляет обновления в upstream репозитория repo.

Ключевые аргументы:

• remote::AbstractString="origin": имя upstream remote, в который будет выполнена отправка.
• remoteurl::AbstractString="": URL remote.
• refspecs=AbstractString[]: определяет свойства отправки.
• force::Bool=false: определяет, будет ли отправка принудительной, перезаписывающей удалённую ветку.
• credentials=nothing: предоставляет учетные данные и/или настройки при аутентификации против частного remote.
• callbacks=Callbacks(): пользовательские обратные вызовы и полезные нагрузки.

Эквивалентно git push [<remoteurl>|<repo>] [<refspecs>].

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

Начинает GitRevWalker walker с коммита cid. Эта функция может быть использована для применения функции ко всем коммитам с определенного года, передав первый коммит этого года в качестве cid, а затем передав полученный w в LibGit2.map.

LibGit2.push_head!(w::GitRevWalker)

Отправьте коммит HEAD и его предков в GitRevWalker w. Это гарантирует, что HEAD и все его предковые коммиты будут встречены во время обхода.

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

Получите push референс-спецификации для указанного rmt. Эти референс-спецификации содержат информацию о том, какие ветки нужно отправить.

Примеры

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 (или дерево, на которое указывает treehash, в репозитории, принадлежащем idx) в индекс idx. Содержимое текущего индекса будет заменено.

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

Попытка автоматического слияния с перемещением текущей ветки, из upstream, если он предоставлен, или в противном случае из ветки отслеживания upstream. newbase — это ветка, на которую нужно переместить. По умолчанию это upstream.

Если возникнут конфликты, которые не могут быть автоматически разрешены, перемещение будет прервано, оставив репозиторий и рабочее дерево в исходном состоянии, и функция выбросит GitError. Это примерно эквивалентно следующему оператору командной строки:

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

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

Получите список всех имен ссылок в репозитории repo.

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

Возвращает Cint, соответствующий типу ref:

• 0, если ссылка недействительна
• 1, если ссылка является идентификатором объекта
• 2, если ссылка символическая

LibGit2.remotes(repo::GitRepo)

Возвращает вектор имен удаленных репозиториев repo.

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

Удалите все файлы с путями, указанными в files, из индекса idx (или из индекса repo).

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

Сбросьте биты val, индексируемые flag, вернув их к 0.

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

Сбросьте состояние payload обратно к начальным значениям, чтобы его можно было использовать снова в колбэке учетных данных. Если предоставлен config, конфигурация также будет обновлена.

Обновляет некоторые записи, определяемые pathspecs, в индексе из дерева целевого коммита.

Устанавливает текущую ветку на указанный идентификатор коммита oid и при необходимости сбрасывает индекс и рабочее дерево, чтобы они соответствовали.

git reset [<committish>] [–] <pathspecs>...

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

Сбросить репозиторий repo в его состояние на id, используя один из трех режимов, заданных 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
# и уберет его из индекса
new_head = LibGit2.reset!(repo, head_oid, mode)

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

Вернуть репозиторий repo в предыдущее состояние State s, например, HEAD ветки до попытки слияния. s можно сгенерировать с помощью функции snapshot.

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

Список количества ревизий между commit1 и commit2 (committish OIDs в строковом формате). Поскольку commit1 и commit2 могут находиться на разных ветках, revcount выполняет список ревизий "лево-право" (и подсчет), возвращая кортеж Int - количество левых и правых коммитов соответственно. Левый (или правый) коммит относится к тому, с какой стороны симметричной разности в дереве коммит доступен.

Эквивалентно 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)

Установите как url для получения, так и url для отправки для remote_name для GitRepo или git-репозитория, расположенного по path. Обычно 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 = 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

Сделайте снимок текущего состояния репозитория 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 для получения дополнительной информации.

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

Проверьте статус файла по пути path в репозитории git repo. Например, это можно использовать для проверки, был ли файл по пути path изменен и нуждается в подготовке и коммите.

stage(ie::IndexEntry) -> Cint

Получите номер стадии ie. Номер стадии 0 представляет текущее состояние рабочей директории, но другие номера могут использоваться в случае конфликта слияния. В таком случае различные номера стадий в IndexEntry описывают, к какой стороне(ам) конфликта принадлежит текущее состояние файла. Стадия 0 — это состояние до попытки слияния, стадия 1 — это изменения, которые были внесены локально, стадии 2 и выше предназначены для изменений из других веток (например, в случае многоветвевого "октопусного" слияния могут использоваться стадии 2, 3 и 4).

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

Создайте новый git-тег tag (например, "v0.5") в репозитории repo, на коммите commit.

Ключевые аргументы:

• msg::AbstractString="": сообщение для тега.
• force::Bool=false: если true, существующие ссылки будут перезаписаны.
• sig::Signature=Signature(repo): подпись теггера.

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

Удалите git-тег tag из репозитория repo.

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

Получите список всех тегов в репозитории git repo.

LibGit2.target(tag::GitTag)

GitHash целевого объекта tag.

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

Переверните биты val, индексируемые flag, так что если бит равен 0, он станет 1 после переключения, и наоборот.

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

Примените функцию f к репозиторию git repo, сделав snapshot перед применением f. Если в f произойдет ошибка, repo будет возвращен в состояние снимка с помощью restore. Ошибка, которая произошла, будет повторно выброшена, но состояние repo не будет повреждено.

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

Обход записей в tree и его поддеревьях в пост- или пре- порядке. Пре- порядок означает, что мы начинаем с корня, а затем обходим самое левое поддерево (и рекурсивно продолжаем вниз по самым левым поддеревьям этого поддерева), перемещаясь вправо по поддеревьям. Пост- порядок означает, что мы начинаем с низа самого левого поддерева, поднимаемся вверх по нему, затем обходим следующее правое поддерево (снова начиная с низа) и, наконец, посещаем корень дерева последним.

Параметр функции f должен иметь следующую сигнатуру:

(String, GitTreeEntry) -> Cint

Отрицательное значение, возвращаемое из f, останавливает обход дерева. Положительное значение означает, что запись будет пропущена, если post равно false.

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

Определите, имеет ли ветка, содержащая ref, указанную ветку upstream.

Возвращает либо GitReference на ветку upstream, если она существует, либо nothing, если запрашиваемая ветка не имеет соответствующей ветки upstream.

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

Обновите все файлы с путями, указанными в files, в индексе idx (или в индексе repo). Сравните состояние каждого файла в индексе с текущим состоянием на диске, удаляя его, если он был удален на диске, или обновляя его запись в объектной базе данных.

url(rmt::GitRemote)

Получите URL для извлечения удаленного git-репозитория.

Примеры

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, гарантируя вызов close на obj после успешного завершения f или возникновения ошибки. Обеспечивает, чтобы выделенные ресурсы git были завершены, как только они больше не нужны.

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

Вспомогательная функция управления ресурсами. Применяет f к args, сначала создавая экземпляр типа T из args. Убедитесь, что close вызывается на результирующем объекте после успешного возврата f или выбрасывания ошибки. Обеспечивает, чтобы выделенные ресурсы git были завершены, как только они больше не нужны. Если f выбрасывает ошибку, отображается предупреждение, содержащее ошибку.

LibGit2.workdir(repo::GitRepo)

Возвращает местоположение рабочей директории repo. Это вызовет ошибку для голых репозиториев.

См. также gitdir, path.

(::Type{T})(te::GitTreeEntry) где T<:GitObject

Получите объект git, на который ссылается te, и верните его в качестве его фактического типа (тип entrytype покажет), например, GitBlob или GitTag.

Примеры

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

Учетные данные, которые поддерживают только параметры user и password

Тип учетных данных SSH

isfilled(cred::AbstractCredential) -> Bool

Проверяет, что учетные данные готовы к использованию для аутентификации.

Кэширует информацию о учетных данных для повторного использования

LibGit2.CredentialPayload

Сохраняет состояние между несколькими вызовами обратного вызова учетных данных для одного и того же URL. Ожидается, что экземпляр CredentialPayload будет reset!, когда он будет использоваться с другим URL.

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

Сохраните учетные данные payload для повторного использования в будущем при аутентификации. Должен вызываться только после успешной аутентификации.

Ключевое слово shred управляет тем, следует ли уничтожить конфиденциальную информацию в поле учетных данных payload. Должно быть установлено в false только во время тестирования.

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

Отменяет учетные данные payload от повторного использования в будущей аутентификации. Должен вызываться только в случае неудачной аутентификации.

Ключевое слово shred управляет тем, следует ли уничтожить конфиденциальную информацию в поле учетных данных. Должно быть установлено в false только во время тестирования.

Приоритет уровня конфигурационного файла.

Эти уровни приоритета соответствуют естественной логике эскалации (от более высокого к более низкому) при поиске записей конфигурации в git.

• CONFIG_LEVEL_DEFAULT - Открыть глобальные, XDG и системные конфигурационные файлы, если они доступны.
• CONFIG_LEVEL_PROGRAMDATA - Системный уровень в Windows, для совместимости с портативным git
• CONFIG_LEVEL_SYSTEM - Системный конфигурационный файл; /etc/gitconfig на системах Linux
• CONFIG_LEVEL_XDG - Конфигурационный файл, совместимый с XDG; обычно ~/.config/git/config
• CONFIG_LEVEL_GLOBAL - Конфигурационный файл, специфичный для пользователя (также называемый глобальным конфигурационным файлом); обычно ~/.gitconfig
• CONFIG_LEVEL_LOCAL - Конфигурационный файл, специфичный для репозитория; $WORK_DIR/.git/config на непустых репозиториях
• CONFIG_LEVEL_APP - Конфигурационный файл, специфичный для приложения; свободно определяемый приложениями
• CONFIG_HIGHEST_LEVEL - Представляет собой конфигурационный файл самого высокого доступного уровня (т.е. наиболее специфичный конфигурационный файл, который фактически загружен)