LibGit2

LibGit2.Buffer

Un tampon de données pour exporter des données de libgit2. Correspond à la structure git_buf.

Lors de la récupération de données depuis LibGit2, une utilisation typique ressemblerait à :

buf_ref = Ref(Buffer())
@check ccall(..., (Ptr{Buffer},), buf_ref)
# opération sur buf_ref
free(buf_ref)

En particulier, notez que LibGit2.free doit être appelé par la suite sur l'objet Ref.

LibGit2.CheckoutOptions

Correspond à la structure git_checkout_options.

Les champs représentent :

• version : version de la structure utilisée, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• checkout_strategy : détermine comment gérer les conflits et si le checkout/recréer des fichiers manquants doit être forcé.
• disable_filters : si non nul, n'applique pas de filtres comme CLRF (pour convertir les nouvelles lignes de fichiers entre UNIX et DOS).
• dir_mode : mode de lecture/écriture/accès pour tous les répertoires impliqués dans le checkout. Par défaut, c'est 0755.
• file_mode : mode de lecture/écriture/accès pour tous les fichiers impliqués dans le checkout. Par défaut, c'est 0755 ou 0644, selon le blob.
• file_open_flags : drapeaux utilisés pour ouvrir des fichiers pendant le checkout.
• notify_flags : Drapeaux pour quel type de conflits l'utilisateur doit être informé.
• notify_cb : Une fonction de rappel optionnelle pour notifier l'utilisateur si un conflit de checkout se produit. Si cette fonction retourne une valeur non nulle, le checkout sera annulé.
• notify_payload : Charge utile pour la fonction de rappel de notification.
• progress_cb : Une fonction de rappel optionnelle pour afficher la progression du checkout.
• progress_payload : Charge utile pour le rappel de progression.
• paths : Si non vide, décrit quels chemins rechercher pendant le checkout. Si vide, le checkout se produira sur tous les fichiers du dépôt.
• baseline : Contenu attendu du workdir, capturé dans un (pointeur vers un) GitTree. Par défaut, c'est l'état de l'arbre à HEAD.
• baseline_index : Contenu attendu du workdir, capturé dans un (pointeur vers un) GitIndex. Par défaut, c'est l'état de l'index à HEAD.
• target_directory : Si non vide, checkout dans ce répertoire au lieu du workdir.
• ancestor_label : En cas de conflits, le nom du côté ancêtre commun.
• our_label : En cas de conflits, le nom de notre côté.
• their_label : En cas de conflits, le nom de leur côté.
• perfdata_cb : Une fonction de rappel optionnelle pour afficher les données de performance.
• perfdata_payload : Charge utile pour le rappel de performance.

LibGit2.CloneOptions

Correspond à la structure git_clone_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• checkout_opts : Les options pour effectuer le checkout du distant dans le cadre du clonage.
• fetch_opts : Les options pour effectuer le fetch pré-checkout du distant dans le cadre du clonage.
• bare : Si 0, cloner le dépôt distant complet. Si non nul, effectuer un clonage nu, dans lequel il n'y a pas de copie locale des fichiers sources dans le dépôt et les gitdir et workdir sont les mêmes.
• localclone : Indicateur pour savoir s'il faut cloner une base de données d'objets locale ou faire un fetch. La valeur par défaut est de laisser git décider. Il n'utilisera pas le transport conscient de git pour un clonage local, mais l'utilisera pour les URL qui commencent par file://.
• checkout_branch : Le nom de la branche à vérifier. Si une chaîne vide, la branche par défaut du distant sera vérifiée.
• repository_cb : Un rappel optionnel qui sera utilisé pour créer le nouveau dépôt dans lequel le clonage est effectué.
• repository_cb_payload : La charge utile pour le rappel du dépôt.
• remote_cb : Un rappel optionnel utilisé pour créer le GitRemote avant de faire le clonage à partir de celui-ci.
• remote_cb_payload : La charge utile pour le rappel distant.

LibGit2.DescribeOptions

Correspond à la structure git_describe_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• max_candidates_tags : considérer ce nombre de tags les plus récents dans refs/tags pour décrire un commit. Par défaut, 10 (de sorte que les 10 tags les plus récents soient examinés pour voir s'ils décrivent un commit).
• describe_strategy : s'il faut considérer toutes les entrées dans refs/tags (équivalent à git-describe --tags) ou toutes les entrées dans refs/ (équivalent à git-describe --all). La valeur par défaut est de n'afficher que les tags annotés. Si Consts.DESCRIBE_TAGS est passé, tous les tags, annotés ou non, seront considérés. Si Consts.DESCRIBE_ALL est passé, toute référence dans refs/ sera considérée.
• pattern : ne considérer que les tags qui correspondent à pattern. Prend en charge l'expansion glob.
• only_follow_first_parent : lors de la recherche de la distance d'une référence correspondante à l'objet décrit, ne considérer que la distance par rapport au premier parent.
• show_commit_oid_as_fallback : si aucune référence correspondante ne peut être trouvée pour décrire un commit, afficher le GitHash du commit au lieu de lancer une erreur (le comportement par défaut).

LibGit2.DescribeFormatOptions

Correspond à la structure git_describe_format_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• abbreviated_size : limite inférieure sur la taille du GitHash abrégé à utiliser, par défaut 7.
• always_use_long_format : défini sur 1 pour utiliser le format long pour les chaînes même si un format court peut être utilisé.
• dirty_suffix : s'il est défini, cela sera ajouté à la fin de la chaîne de description si le workdir est sale.

LibGit2.DiffDelta

Description des changements apportés à une entrée. Correspond à la structure git_diff_delta.

Les champs représentent :

• status : L'un des Consts.DELTA_STATUS, indiquant si le fichier a été ajouté/modifié/supprimé.
• flags : Drapeaux pour le delta et les objets de chaque côté. Détermine s'il faut traiter le(s) fichier(s) comme binaire/texte, s'ils existent de chaque côté du diff, et si les identifiants d'objet sont connus pour être corrects.
• similarity : Utilisé pour indiquer si un fichier a été renommé ou copié.
• nfiles : Le nombre de fichiers dans le delta (par exemple, si le delta a été exécuté sur un identifiant de commit de sous-module, il peut contenir plus d'un fichier).
• old_file : Un DiffFile contenant des informations sur le(s) fichier(s) avant les changements.
• new_file : Un DiffFile contenant des informations sur le(s) fichier(s) après les changements.

LibGit2.DiffFile

Description d'un côté d'un delta. Correspond à la structure git_diff_file.

Les champs représentent :

• id : le GitHash de l'élément dans le diff. Si l'élément est vide de ce côté du diff (par exemple, si le diff concerne la suppression d'un fichier), cela sera GitHash(0).
• path : un chemin terminé par NULL vers l'élément relatif au répertoire de travail du dépôt.
• size : la taille de l'élément en octets.
• flags : une combinaison des drapeaux git_diff_flag_t. Le i-ème bit de cet entier définit le i-ème drapeau.
• mode : le mode stat pour l'élément.
• id_abbrev : présent uniquement dans les versions de LibGit2 supérieures ou égales à 0.25.0. La longueur du champ id lorsqu'il est converti en utilisant string. Généralement égal à OID_HEXSZ (40).

LibGit2.DiffOptionsStruct

Correspond à la structure git_diff_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• flags : drapeaux contrôlant quels fichiers apparaîtront dans le diff. Par défaut, DIFF_NORMAL.
• ignore_submodules : indique s'il faut examiner les fichiers dans les sous-modules ou non. Par défaut, SUBMODULE_IGNORE_UNSPECIFIED, ce qui signifie que la configuration du sous-module contrôlera s'il apparaît dans le diff ou non.
• pathspec : chemin vers les fichiers à inclure dans le diff. Par défaut, tous les fichiers du dépôt sont utilisés.
• notify_cb : rappel optionnel qui notifiera l'utilisateur des changements dans le diff à mesure que des deltas de fichiers y sont ajoutés.
• progress_cb : rappel optionnel qui affichera la progression du diff. Pertinent uniquement sur les versions de libgit2 au moins aussi récentes que 0.24.0.
• payload : la charge utile à passer à notify_cb et progress_cb.
• context_lines : le nombre de lignes inchangées utilisées pour définir les bords d'un hunk. C'est également le nombre de lignes qui seront affichées avant/après un hunk pour fournir un contexte. Par défaut, 3.
• interhunk_lines : le nombre maximum de lignes inchangées entre deux hunks séparés autorisées avant que les hunks ne soient combinés. Par défaut, 0.
• id_abbrev : définit la longueur de l'abrégé GitHash à imprimer. Par défaut, 7.
• max_size : la taille maximale d'un fichier blob. Au-dessus de cette taille, il sera traité comme un blob binaire. La valeur par défaut est 512 Mo.
• old_prefix : le répertoire de fichiers virtuel dans lequel placer les anciens fichiers d'un côté du diff. Par défaut, "a".
• new_prefix : le répertoire de fichiers virtuel dans lequel placer les nouveaux fichiers d'un côté du diff. Par défaut, "b".

LibGit2.FetchHead

Contient les informations sur HEAD lors d'un fetch, y compris le nom et l'URL de la branche à partir de laquelle il a été récupéré, l'oid de HEAD, et si le HEAD récupéré a été fusionné localement.

Les champs représentent :

• name : Le nom dans la base de données de références locales du fetch head, par exemple, "refs/heads/master".
• url : L'URL du fetch head.
• oid : Le GitHash du sommet du fetch head.
• ismerge : Indicateur booléen indiquant si les modifications à distance ont été fusionnées dans la copie locale ou non. Si true, la copie locale est à jour avec le fetch head distant.

LibGit2.FetchOptions

Correspond à la structure git_fetch_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• callbacks : rappels distants à utiliser pendant le fetch.
• prune : s'il faut effectuer un prune après le fetch ou non. La valeur par défaut est d'utiliser le paramètre du GitConfig.
• update_fetchhead : s'il faut mettre à jour le FetchHead après le fetch. La valeur par défaut est d'effectuer la mise à jour, ce qui est le comportement normal de git.
• download_tags : s'il faut télécharger les tags présents sur le distant ou non. La valeur par défaut est de demander les tags pour les objets qui sont de toute façon téléchargés depuis le serveur.
• proxy_opts : options pour se connecter au distant via un proxy. Voir ProxyOptions. Présent uniquement sur les versions de libgit2 supérieures ou égales à 0.25.0.
• custom_headers : tous les en-têtes supplémentaires nécessaires pour le fetch. Présent uniquement sur les versions de libgit2 supérieures ou égales à 0.24.0.

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

Un commit git annoté contient des informations sur la façon dont il a été recherché et pourquoi, de sorte que les opérations de rebase ou de fusion disposent de plus d'informations sur le contexte du commit. Les fichiers de conflit contiennent des informations sur les branches source/cible dans la fusion qui sont en conflit, par exemple. Un commit annoté peut faire référence à la pointe d'une branche distante, par exemple lorsqu'un FetchHead est passé, ou à un chef de branche décrit à l'aide de GitReference.

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

Construit un objet GitBlame pour le fichier à path, en utilisant les informations de changement tirées de l'historique de repo. L'objet GitBlame enregistre qui a changé quels morceaux du fichier, quand et comment. options contrôle comment séparer le contenu du fichier et quels commits interroger - voir BlameOptions pour plus d'informations.

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

Retourne un objet GitBlob à partir de repo spécifié par hash/spec.

• hash est un hash complet (GitHash) ou partiel (GitShortHash).
• spec est une spécification textuelle : voir la documentation git pour une liste complète.

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

Retourne un objet GitCommit à partir de repo spécifié par hash/spec.

• hash est un hash complet (GitHash) ou partiel (GitShortHash).
• spec est une spécification textuelle : voir la documentation git pour une liste complète.

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

Créez un nouveau GitConfig en chargeant les informations de configuration à partir du fichier à path. Voir addfile pour plus d'informations sur les options level, repo et force.

GitConfig(repo::GitRepo)

Obtenez la configuration stockée pour le dépôt git repo. Si repo n'a pas de fichier de configuration spécifique défini, la configuration git par défaut sera utilisée.

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

Obtenez la configuration git par défaut en chargeant les fichiers de configuration globaux et système dans une configuration priorisée. Cela peut être utilisé pour accéder aux options de configuration par défaut en dehors d'un dépôt git spécifique.

GitHash

Un identifiant d'objet git, basé sur le hachage sha-1. C'est une chaîne de 20 octets (40 chiffres hexadécimaux) utilisée pour identifier un GitObject dans un dépôt.

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

Retourne l'objet spécifié (GitCommit, GitBlob, GitTree ou GitTag) du repo spécifié par hash/spec.

• hash est un hash complet (GitHash) ou partiel (GitShortHash).
• spec est une spécification textuelle : voir la documentation git pour une liste complète.

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

Recherchez un dépôt git distant en utilisant son nom et son URL. Utilise le refspec de récupération par défaut.

Exemples

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

Recherchez un dépôt git distant en utilisant le nom et l'URL du dépôt, ainsi que des spécifications sur la façon de récupérer depuis le distant (par exemple, quelle branche distante récupérer).

Exemples

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

Recherchez un dépôt git distant en utilisant uniquement son URL, pas son nom.

Exemples

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

LibGit2.GitRepo(path::AbstractString)

Ouvre un dépôt git à path.

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

Ouvrir un dépôt git à path avec des contrôles étendus (par exemple, si l'utilisateur actuel doit être membre d'un groupe d'accès spécial pour lire path).

GitRevWalker(repo::GitRepo)

Un GitRevWalker parcourt les révisions (c'est-à-dire les commits) d'un dépôt git repo. C'est une collection des commits dans le dépôt, et il prend en charge l'itération et les appels à LibGit2.map et LibGit2.count (par exemple, LibGit2.count pourrait être utilisé pour déterminer quel pourcentage de commits dans un dépôt a été réalisé par un certain auteur).

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

Ici, LibGit2.count trouve le nombre de commits le long de la marche avec un certain GitHash. Puisque le GitHash est unique à un commit, cnt sera 1.

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

Un identifiant d'objet git abrégé, qui peut être utilisé pour identifier un objet git lorsqu'il est unique, consistant des len premiers chiffres hexadécimaux de hash (les chiffres restants sont ignorés).

LibGit2.GitSignature

Ceci est un wrapper Julia autour d'un pointeur vers un objet git_signature.

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

Collecte des informations sur l'état de chaque fichier dans le dépôt git repo (par exemple, si le fichier est modifié, mis en scène, etc.). status_opts peut être utilisé pour définir diverses options, par exemple, s'il faut ou non examiner les fichiers non suivis ou s'il faut inclure ou non les sous-modules. Voir StatusOptions pour plus d'informations.

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

Retourne un objet GitTag à partir de repo spécifié par hash/spec.

• hash est un hash complet (GitHash) ou partiel (GitShortHash).
• spec est une spécification textuelle : voir la documentation git pour une liste complète.

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

Retourne un objet GitTree de repo spécifié par hash/spec.

• hash est un hash complet (GitHash) ou partiel (GitShortHash).
• spec est une spécification textuelle : voir les docs git pour une liste complète.

LibGit2.IndexEntry

Représentation en mémoire d'une entrée de fichier dans l'index. Correspond à la structure git_index_entry.

LibGit2.IndexTime

Correspond à la structure git_index_time.

LibGit2.BlameOptions

Correspond à la structure git_blame_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• flags : l'un de Consts.BLAME_NORMAL ou Consts.BLAME_FIRST_PARENT (les autres drapeaux de blame ne sont pas encore implémentés par libgit2).
• min_match_characters : le nombre minimum de caractères alphanumériques qui doivent changer dans un commit pour que le changement soit associé à ce commit. La valeur par défaut est 20. N'entre en vigueur que si l'un des drapeaux Consts.BLAME_*_COPIES est utilisé, ce que libgit2 n'implémente pas encore.
• newest_commit : le GitHash du commit le plus récent à partir duquel examiner les changements.
• oldest_commit : le GitHash du commit le plus ancien à partir duquel examiner les changements.
• min_line : la première ligne du fichier à partir de laquelle commencer à blâmer. La valeur par défaut est 1.
• max_line : la dernière ligne du fichier à laquelle blâmer. La valeur par défaut est 0, ce qui signifie la dernière ligne du fichier.

LibGit2.MergeOptions

Correspond à la structure git_merge_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.

• flags : un enum pour les drapeaux décrivant le comportement de fusion. Défini dans git_merge_flag_t. L'énumération Julia correspondante est GIT_MERGE et a les valeurs :

  • MERGE_FIND_RENAMES : détecter si un fichier a été renommé entre l'ancêtre commun et le côté "notre" ou "leur" de la fusion. Permet des fusions où un fichier a été renommé.
  • MERGE_FAIL_ON_CONFLICT : sortir immédiatement si un conflit est trouvé plutôt que d'essayer de le résoudre.
  • MERGE_SKIP_REUC : ne pas écrire l'extension REUC sur l'index résultant de la fusion.
  • MERGE_NO_RECURSIVE : si les commits à fusionner ont plusieurs bases de fusion, utiliser la première, plutôt que d'essayer de fusionner les bases de manière récursive.

• rename_threshold : à quel point deux fichiers doivent être similaires pour considérer l'un comme un renommage de l'autre. C'est un entier qui fixe le pourcentage de similarité. La valeur par défaut est 50.

• target_limit : le nombre maximum de fichiers à comparer pour rechercher des renommages. La valeur par défaut est 200.

• metric : fonction personnalisée optionnelle à utiliser pour déterminer la similarité entre deux fichiers pour la détection de renommage.

• recursion_limit : la limite supérieure sur le nombre de fusions d'ancêtres communs à effectuer pour essayer de construire une nouvelle base de fusion virtuelle pour la fusion. La valeur par défaut est sans limite. Ce champ n'est présent que dans les versions de libgit2 plus récentes que 0.24.0.

• default_driver : le pilote de fusion à utiliser si les deux côtés ont changé. Ce champ n'est présent que dans les versions de libgit2 plus récentes que 0.25.0.

• file_favor : comment gérer les contenus de fichiers conflictuels pour le pilote text.

  • MERGE_FILE_FAVOR_NORMAL : si les deux côtés de la fusion ont des modifications dans une section, notez le conflit dans l'index que git checkout utilisera pour créer un fichier de fusion, que l'utilisateur pourra ensuite référencer pour résoudre les conflits. C'est la valeur par défaut.
  • MERGE_FILE_FAVOR_OURS : si les deux côtés de la fusion ont des modifications dans une section, utilisez la version du côté "notre" de la fusion dans l'index.
  • MERGE_FILE_FAVOR_THEIRS : si les deux côtés de la fusion ont des modifications dans une section, utilisez la version du côté "leur" de la fusion dans l'index.
  • MERGE_FILE_FAVOR_UNION : si les deux côtés de la fusion ont des modifications dans une section, incluez chaque ligne unique des deux côtés dans le fichier qui est mis dans l'index.

• file_flags : directives pour fusionner des fichiers.

LibGit2.ProxyOptions

Options pour se connecter via un proxy.

Correspond à la structure git_proxy_options.

Les champs représentent :

• version : version de la structure utilisée, au cas où cela changerait plus tard. Pour l'instant, toujours 1.

• proxytype : un enum pour le type de proxy à utiliser. Défini dans git_proxy_t. L'énumération Julia correspondante est GIT_PROXY et a les valeurs :

  • PROXY_NONE : ne pas tenter la connexion via un proxy.
  • PROXY_AUTO : tenter de déterminer la configuration du proxy à partir de la configuration git.
  • PROXY_SPECIFIED : se connecter en utilisant l'URL donnée dans le champ url de cette structure.

  Par défaut, il s'agit de détecter automatiquement le type de proxy.

• url : l'URL du proxy.

• credential_cb : un pointeur vers une fonction de rappel qui sera appelée si le distant nécessite une authentification pour se connecter.

• certificate_cb : un pointeur vers une fonction de rappel qui sera appelée si la vérification du certificat échoue. Cela permet à l'utilisateur de décider s'il souhaite ou non continuer la connexion. Si la fonction retourne 1, la connexion sera autorisée. Si elle retourne 0, la connexion ne sera pas autorisée. Une valeur négative peut être utilisée pour retourner des erreurs.

• payload : la charge utile à fournir aux deux fonctions de rappel.

Exemples

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

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

LibGit2.PushOptions

Correspond à la structure git_push_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• parallelism : si un fichier pack doit être créé, cette variable définit le nombre de threads de travail qui seront lancés par le packbuilder. Si 0, le packbuilder définira automatiquement le nombre de threads à utiliser. La valeur par défaut est 1.
• callbacks : les callbacks (par exemple, pour l'authentification avec le distant) à utiliser pour le push.
• proxy_opts : uniquement pertinent si la version de LibGit2 est supérieure ou égale à 0.25.0. Définit les options pour utiliser un proxy pour communiquer avec un distant. Voir ProxyOptions pour plus d'informations.
• custom_headers : uniquement pertinent si la version de LibGit2 est supérieure ou égale à 0.24.0. En-têtes supplémentaires nécessaires pour l'opération de push.

LibGit2.RebaseOperation

Décrit une seule instruction/opération à effectuer pendant le rebase. Correspond à la structure git_rebase_operation.

Les champs représentent :

• optype : le type d'opération de rebase actuellement en cours. Les options sont :

  • REBASE_OPERATION_PICK : cherry-pick le commit en question.
  • REBASE_OPERATION_REWORD : cherry-pick le commit en question, mais réécrire son message en utilisant l'invite.
  • REBASE_OPERATION_EDIT : cherry-pick le commit en question, mais permettre à l'utilisateur de modifier le contenu du commit et son message.
  • REBASE_OPERATION_SQUASH : écraser le commit en question dans le commit précédent. Les messages de commit des deux commits seront fusionnés.
  • REBASE_OPERATION_FIXUP : écraser le commit en question dans le commit précédent. Seul le message de commit du commit précédent sera utilisé.
  • REBASE_OPERATION_EXEC : ne pas cherry-pick un commit. Exécuter une commande et continuer si la commande se termine avec succès.

• id : le GitHash du commit sur lequel on travaille pendant cette étape de rebase.

• exec : dans le cas où REBASE_OPERATION_EXEC est utilisé, la commande à exécuter pendant cette étape (par exemple, exécuter la suite de tests après chaque commit).

LibGit2.RebaseOptions

Correspond à la structure git_rebase_options.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• quiet : informer les autres clients git aidant avec/travaillant sur le rebase que le rebase doit être effectué "silencieusement". Utilisé pour l'interopérabilité. La valeur par défaut est 1.
• inmemory : démarrer un rebase en mémoire. Les appelants travaillant sur le rebase peuvent passer par ses étapes et valider les modifications, mais ne peuvent pas revenir en arrière sur HEAD ou mettre à jour le dépôt. Le workdir ne sera pas modifié. Présent uniquement sur les versions de libgit2 supérieures ou égales à 0.24.0.
• rewrite_notes_ref : nom de la référence aux notes à utiliser pour réécrire les notes de commit à la fin du rebase.
• merge_opts : options de fusion contrôlant comment les arbres seront fusionnés à chaque étape du rebase. Présent uniquement sur les versions de libgit2 supérieures ou égales à 0.24.0.
• checkout_opts : options de checkout pour écrire des fichiers lors de l'initialisation du rebase, en le parcourant et en l'abandonnant. Voir CheckoutOptions pour plus d'informations.

LibGit2.RemoteCallbacks

Paramètres de rappel. Correspond à la structure git_remote_callbacks.

LibGit2.SignatureStruct

Une signature d'action (par exemple pour les committers, taggers, etc). Correspond à la structure git_signature.

Les champs représentent :

• name : Le nom complet du committer ou de l'auteur du commit.
• email : L'email auquel le committer/auteur peut être contacté.
• when : une TimeStruct indiquant quand le commit a été créé/commité dans le dépôt.

LibGit2.StatusEntry

Fournit les différences entre le fichier tel qu'il existe dans HEAD et l'index, et fournit les différences entre l'index et le répertoire de travail. Correspond à la structure git_status_entry.

Les champs représentent :

• status : contient les indicateurs de statut pour le fichier, indiquant s'il est à jour ou s'il a été modifié d'une manière ou d'une autre dans l'index ou l'arbre de travail.
• head_to_index : un pointeur vers un DiffDelta qui encapsule la ou les différences entre le fichier tel qu'il existe dans HEAD et dans l'index.
• index_to_workdir : un pointeur vers un DiffDelta qui encapsule la ou les différences entre le fichier tel qu'il existe dans l'index et dans le workdir.

LibGit2.StatusOptions

Options pour contrôler comment git_status_foreach_ext() émettra des rappels. Correspond à la structure git_status_opt_t.

Les champs représentent :

• version : version de la structure en cours d'utilisation, au cas où cela changerait plus tard. Pour l'instant, toujours 1.
• show : un indicateur pour quels fichiers examiner et dans quel ordre. La valeur par défaut est Consts.STATUS_SHOW_INDEX_AND_WORKDIR.
• flags : indicateurs pour contrôler les rappels utilisés dans un appel de statut.
• pathspec : un tableau de chemins à utiliser pour le filtrage des chemins. Le comportement du filtrage des chemins variera en fonction des valeurs de show et flags.
• Le baseline est l'arbre à utiliser pour la comparaison avec le répertoire de travail et l'index ; par défaut, c'est HEAD.

LibGit2.StrArrayStruct

Une représentation de LibGit2 d'un tableau de chaînes de caractères. Correspond à la structure git_strarray.

Lors de la récupération de données depuis LibGit2, une utilisation typique ressemblerait à :

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

En particulier, notez que LibGit2.free doit être appelé par la suite sur l'objet Ref.

Inversement, lors du passage d'un vecteur de chaînes de caractères à LibGit2, il est généralement plus simple de s'appuyer sur la conversion implicite :

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

Notez qu'aucun appel à free n'est requis car les données sont allouées par Julia.

LibGit2.TimeStruct

Temps dans une signature. Correspond à la structure git_time.

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

Ajoute un fichier de configuration git existant situé à path à la configuration GitConfig actuelle cfg. Si le fichier n'existe pas, il sera créé.

• level définit le niveau de priorité de la configuration git et est déterminé par

Consts.GIT_CONFIG.

• repo est un dépôt optionnel pour permettre l'analyse des inclusions conditionnelles.
• Si force est false et qu'une configuration pour le niveau de priorité donné existe déjà,

addfile renverra une erreur. Si force est true, la configuration existante sera remplacée par celle du fichier à path.

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

Ajoutez tous les fichiers dont les chemins sont spécifiés par files à l'index idx (ou l'index du repo). Si le fichier existe déjà, l'entrée de l'index sera mise à jour. Si le fichier n'existe pas déjà, il sera nouvellement ajouté à l'index. files peut contenir des motifs glob qui seront développés et tous les fichiers correspondants seront ajoutés (à moins que INDEX_ADD_DISABLE_PATHSPEC_MATCH ne soit défini, voir ci-dessous). Si un fichier a été ignoré (dans .gitignore ou dans la configuration), il ne sera pas ajouté, à moins qu'il ne soit déjà suivi dans l'index, auquel cas il sera mis à jour. L'argument clé flags est un ensemble de bits qui contrôlent le comportement par rapport aux fichiers ignorés :

• Consts.INDEX_ADD_DEFAULT - par défaut, décrit ci-dessus.
• Consts.INDEX_ADD_FORCE - ignorer les règles d'ignorance existantes et forcer l'ajout du fichier à l'index même s'il est déjà ignoré.
• Consts.INDEX_ADD_CHECK_PATHSPEC - ne peut pas être utilisé en même temps que INDEX_ADD_FORCE. Vérifiez que chaque fichier dans files qui existe sur le disque n'est pas dans la liste d'ignorance. Si l'un des fichiers est ignoré, la fonction renverra EINVALIDSPEC.
• Consts.INDEX_ADD_DISABLE_PATHSPEC_MATCH - désactiver la correspondance glob, et n'ajouter que les fichiers à l'index qui correspondent exactement aux chemins spécifiés dans files.

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

Ajoute un fetch refspec pour le rmt spécifié. Ce refspec contiendra des informations sur quelle(s) branche(s) récupérer.

Exemples

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)

Ajoute un push refspec pour le rmt spécifié. Ce refspec contiendra des informations sur quelle(s) branche(s) pousser.

Exemples

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)

Lit le fichier à path et l'ajoute à la base d'objets de repo en tant que blob détaché. Retourne le GitHash du blob résultant.

Exemples

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)

Retourne la Signature de l'auteur du commit c. L'auteur est la personne qui a apporté des modifications aux fichiers concernés. Voir aussi committer.

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

Retourne tous les auteurs des commits dans le dépôt repo.

Exemples

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)

# sera un Vector de [sig, sig]
auths = LibGit2.authors(repo)

branch(repo::GitRepo)

Équivalent à git branch. Crée une nouvelle branche à partir du HEAD actuel.

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

Créez une nouvelle branche git dans le dépôt repo. commit est le GitHash, sous forme de chaîne, qui sera le début de la nouvelle branche. Si commit est une chaîne vide, le HEAD actuel sera utilisé.

Les arguments clés sont :

• track::AbstractString="": le nom de la branche distante que cette nouvelle branche doit suivre, le cas échéant. Si vide (par défaut), aucune branche distante ne sera suivie.
• force::Bool=false: si true, la création de la branche sera forcée.
• set_head::Bool=true: si true, après la création de la branche, le HEAD de la branche sera défini comme le HEAD de repo.

Équivalent à git checkout [-b|-B] <branch_name> [<commit>] [--track <track>].

Exemples

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

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

Équivalent à git checkout [-f] --detach <commit>. Effectue le checkout du commit git commit (un GitHash sous forme de chaîne) dans repo. Si force est true, force le checkout et abandonne toutes les modifications en cours. Notez que cela détache le HEAD actuel.

Exemples

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
# échouerait sans le force=true
# puisque le fichier a des modifications
LibGit2.checkout!(repo, string(commit_oid), force=true)

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

Clone le dépôt distant à repo_url (qui peut être une URL distante ou un chemin sur le système de fichiers local) vers repo_path (qui doit être un chemin sur le système de fichiers local). Les options pour le clonage, telles que la possibilité d'effectuer un clonage nu ou non, sont définies par CloneOptions.

Exemples

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

Clone un dépôt distant situé à repo_url vers l'emplacement du système de fichiers local repo_path.

Les arguments de mot-clé sont :

• branch::AbstractString="": quelle branche du dépôt distant cloner, si ce n'est pas la branche par défaut du dépôt (généralement master).
• isbare::Bool=false: si true, clone le dépôt distant en tant que dépôt nu, ce qui fera de repo_path lui-même le répertoire git au lieu de repo_path/.git. Cela signifie qu'un arbre de travail ne peut pas être extrait. Joue le rôle de l'argument de la CLI git --bare.
• remote_cb::Ptr{Cvoid}=C_NULL: un rappel qui sera utilisé pour créer le dépôt distant avant qu'il ne soit cloné. Si C_NULL (la valeur par défaut), aucune tentative ne sera faite pour créer le dépôt distant - il sera supposé déjà exister.
• credentials::Creds=nothing: fournit des identifiants et/ou des paramètres lors de l'authentification contre un dépôt privé.
• callbacks::Callbacks=Callbacks(): rappels et charges utiles fournis par l'utilisateur.

Équivalent à git clone [-b <branch>] [--bare] <repo_url> <repo_path>.

Exemples

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

Wrapper autour de git_commit_create. Créez un commit dans le dépôt repo. msg est le message du commit. Retourne l'OID du nouveau commit.

Les arguments clés sont :

• refname::AbstractString=Consts.HEAD_FILE : si non NULL, le nom de la référence à mettre à jour pour pointer vers le nouveau commit. Par exemple, "HEAD" mettra à jour la HEAD de la branche actuelle. Si la référence n'existe pas encore, elle sera créée.
• author::Signature = Signature(repo) est une Signature contenant des informations sur la personne qui a créé le commit.
• committer::Signature = Signature(repo) est une Signature contenant des informations sur la personne qui a engagé le commit dans le dépôt. Pas nécessairement la même que author, par exemple si author a envoyé un patch à committer qui l'a engagé.
• tree_id::GitHash = GitHash() est un arbre git à utiliser pour créer le commit, montrant son ascendance et sa relation avec tout autre historique. tree doit appartenir à repo.
• parent_ids::Vector{GitHash}=GitHash[] est une liste de commits par GitHash à utiliser comme commits parents pour le nouveau, et peut être vide. Un commit peut avoir plusieurs parents s'il s'agit d'un commit de fusion, par exemple.

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

Engage le patch actuel dans le rebase rb, en utilisant sig comme le committer. Est silencieux si le commit a déjà été appliqué.

committer(c::GitCommit)

Retourne la Signature du committer du commit c. Le committer est la personne qui a engagé les modifications initialement écrites par l'author, mais il n'est pas nécessaire qu'il soit le même que l'author, par exemple, si l'author a envoyé un patch à un committer qui l'a engagé.

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

En utilisant le GitRevWalker walker pour "parcourir" chaque commit dans l'historique du dépôt, trouvez le nombre de commits qui retournent true lorsque f leur est appliqué. Les arguments clés sont : * oid : Le GitHash du commit à partir duquel commencer le parcours. La valeur par défaut est d'utiliser push_head! et donc le commit HEAD et tous ses ancêtres. * by : La méthode de tri. La valeur par défaut est de ne pas trier. D'autres options sont de trier par topologie (LibGit2.Consts.SORT_TOPOLOGICAL), de trier dans le temps (LibGit2.Consts.SORT_TIME, le plus ancien en premier) ou de trier à rebours dans le temps (LibGit2.Consts.SORT_REVERSE, le plus récent en premier). * rev : Indique si l'ordre trié doit être inversé (par exemple, si un tri topologique est utilisé).

Exemples

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 trouve le nombre de commits le long du parcours avec un certain GitHash commit_oid1, en commençant le parcours à partir de ce commit et en avançant dans le temps à partir de celui-ci. Puisque le GitHash est unique à un commit, cnt sera 1.

counthunks(blame::GitBlame)

Retourne le nombre de "hunks" distincts avec un fichier. Un hunk peut contenir plusieurs lignes. Un hunk est généralement un morceau d'un fichier qui a été ajouté/modifié/supprimé ensemble, par exemple, une fonction ajoutée à un fichier source ou une boucle interne qui a été optimisée hors de cette fonction plus tard.

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

Crée une nouvelle branche dans le dépôt repo avec le nom bname, qui pointe vers le commit commit_obj (qui doit faire partie de repo). Si force est true, écrase une branche existante nommée bname si elle existe. Si force est false et qu'une branche existe déjà nommée bname, cette fonction lancera une erreur.

credential_callback(...) -> Cint

Une fonction de rappel d'identification LibGit2 qui fournit différentes fonctionnalités d'acquisition d'identifiants par rapport à un protocole de connexion. Le payload_ptr doit contenir un objet LibGit2.CredentialPayload qui suivra l'état et les paramètres.

Le allowed_types contient un masque de bits des valeurs LibGit2.Consts.GIT_CREDTYPE spécifiant quelles méthodes d'authentification doivent être tentées.

L'authentification des identifiants se fait dans l'ordre suivant (si pris en charge) :

• Agent SSH
• Paire de clés SSH privée/publique
• Nom d'utilisateur/mot de passe en texte clair

Si un utilisateur se voit présenter une invite d'identification, il peut annuler l'invite en tapant ^D (en appuyant sur la touche de contrôle avec la touche d).

Remarque : En raison des spécificités de la procédure d'authentification libgit2, lorsque l'authentification échoue, cette fonction est appelée à nouveau sans aucune indication si l'authentification a réussi ou non. Pour éviter une boucle infinie due à l'utilisation répétée des mêmes identifiants défectueux, nous suivrons l'état à l'aide du payload.

Pour plus de détails, consultez le guide LibGit2 sur l'authentification contre un serveur.

Pointeur de fonction C pour credentials_callback

Retourner l'objet de signature. Libérez-le après utilisation.

LibGit2.delete_branch(branch::GitReference)

Supprime la branche pointée par branch.

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

Montre quels fichiers ont changé dans le dépôt git repo entre les branches branch1 et branch2.

L'argument clé est :

• filter::Set{Consts.DELTA_STATUS}=Set([Consts.DELTA_ADDED, Consts.DELTA_MODIFIED, Consts.DELTA_DELETED])), et il définit les options pour le diff. La valeur par défaut est de montrer les fichiers ajoutés, modifiés ou supprimés.

Retourne uniquement les noms des fichiers qui ont changé, pas leur contenu.

Exemples

LibGit2.branch!(repo, "branch/a")
LibGit2.branch!(repo, "branch/b")
# ajouter un fichier au dépôt
open(joinpath(LibGit2.path(repo),"file"),"w") do f
    write(f, "hello repo
")
end
LibGit2.add!(repo, "file")
LibGit2.commit(repo, "add file")
# retourne ["file"]
filt = Set([LibGit2.Consts.DELTA_ADDED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)
# retourne [] car les fichiers existants n'ont pas été modifiés
filt = Set([LibGit2.Consts.DELTA_MODIFIED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)

Équivalent à git diff --name-only --diff-filter=<filter> <branch1> <branch2>.

entryid(te::GitTreeEntry)

Retourne le GitHash de l'objet auquel te fait référence.

entrytype(te::GitTreeEntry)

Retourne le type de l'objet auquel te fait référence. Le résultat sera l'un des types que objtype retourne, par exemple un GitTree ou un GitBlob.

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

Récupérer depuis le dépôt git distant rmt spécifié, en utilisant refspecs pour déterminer quelle(s) branche(s) distante(s) récupérer. Les arguments de mot-clé sont :

• options : détermine les options pour la récupération, par exemple, s'il faut élaguer par la suite. Voir FetchOptions pour plus d'informations.
• msg : un message à insérer dans les reflogs.

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

Récupère les mises à jour d'un upstream du dépôt repo.

Les arguments clés sont :

• remote::AbstractString="origin" : quel remote, spécifié par nom, de repo à récupérer. Si cela est vide, l'URL sera utilisée pour construire un remote anonyme.
• remoteurl::AbstractString="" : l'URL de remote. Si non spécifié, sera supposé basé sur le nom donné de remote.
• refspecs=AbstractString[] : détermine les propriétés de la récupération.
• credentials=nothing : fournit des identifiants et/ou des paramètres lors de l'authentification contre un remote privé.
• callbacks=Callbacks() : rappels et charges utiles fournis par l'utilisateur.

Équivalent à git fetch [<remoteurl>|<repo>] [<refspecs>].

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

Retourne la liste de tous les fetch heads pour repo, chacun représenté comme un FetchHead, y compris leurs noms, URLs et statuts de fusion.

Exemples

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}

Obtenez les fetch refspecs pour le rmt spécifié. Ces refspecs contiennent des informations sur quelle(s) branche(s) récupérer.

Exemples

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

Pointeur de fonction C pour fetchhead_foreach_callback

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

Trouvez une base de fusion (un ancêtre commun) entre les commits one et two. one et two peuvent être tous deux sous forme de chaîne. Retournez le GitHash de la base de fusion.

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

Effectuez une fusion git sur le dépôt repo, fusionnant les commits avec un historique divergent dans la branche actuelle. Retourne true si la fusion a réussi, false sinon.

Les arguments de mot-clé sont :

• committish::AbstractString="" : Fusionnez le(s) commit(s) nommé(s) dans committish.
• branch::AbstractString="" : Fusionnez la branche branch et tous ses commits depuis qu'elle a divergé de la branche actuelle.
• fastforward::Bool=false : Si fastforward est true, ne fusionnez que si la fusion est un fast-forward (le head de la branche actuelle est un ancêtre des commits à fusionner), sinon refusez de fusionner et retournez false. Cela équivaut à l'option CLI git --ff-only.
• merge_opts::MergeOptions=MergeOptions() : merge_opts spécifie les options pour la fusion, telles que la stratégie de fusion en cas de conflits.
• checkout_opts::CheckoutOptions=CheckoutOptions() : checkout_opts spécifie les options pour l'étape de checkout.

Équivalent à git merge [--ff-only] [<committish> | <branch>].

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

Fusionner les modifications des commits annotés (capturés en tant qu'objets GitAnnotated) anns dans le HEAD du dépôt repo. Les arguments de mot-clé sont :

• merge_opts::MergeOptions = MergeOptions(): options pour la façon de réaliser la fusion, y compris si le fastforward est autorisé. Voir MergeOptions pour plus d'informations.
• checkout_opts::CheckoutOptions = CheckoutOptions(): options pour la façon de réaliser le checkout. Voir CheckoutOptions pour plus d'informations.

anns peut faire référence à des têtes de branches distantes ou locales. Retourne true si la fusion est réussie, sinon retourne false (par exemple, si aucune fusion n'est possible car les branches n'ont pas d'ancêtre commun).

Exemples

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

# fusionner la branche
LibGit2.merge!(repo, [upst_ann])

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

Fusionner les modifications des commits annotés (capturés en tant qu'objets GitAnnotated) anns dans le HEAD du dépôt repo. Si fastforward est true, seule une fusion fastforward est autorisée. Dans ce cas, si des conflits se produisent, la fusion échouera. Sinon, si fastforward est false, la fusion peut produire un fichier de conflit que l'utilisateur devra résoudre.

Les arguments de mot-clé sont :

• merge_opts::MergeOptions = MergeOptions(): options pour la manière de réaliser la fusion, y compris si le fastforward est autorisé. Voir MergeOptions pour plus d'informations.
• checkout_opts::CheckoutOptions = CheckoutOptions(): options pour la manière de réaliser le checkout. Voir CheckoutOptions pour plus d'informations.

anns peut faire référence à des têtes de branches distantes ou locales. Retourne true si la fusion est réussie, sinon retourne false (par exemple, si aucune fusion n'est possible car les branches n'ont pas d'ancêtre commun).

Exemples

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

# fusionner la branche, fastforward
LibGit2.merge!(repo, [upst_ann_1], true)

# conflits de fusion !
upst_ann_2 = LibGit2.GitAnnotated(repo, "branch/b")
# fusionner la branche, essayer de fastforward
LibGit2.merge!(repo, [upst_ann_2], true) # retournera false
LibGit2.merge!(repo, [upst_ann_2], false) # retournera true

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

Fusion fastforward des modifications dans le HEAD actuel. Cela n'est possible que si le commit référencé par ann est un descendant du HEAD actuel (par exemple, si l'on tire des modifications d'une branche distante qui est simplement en avance par rapport à la pointe de la branche locale).

LibGit2.fullname(ref::GitReference)

Retourne le nom de la référence pointée par la référence symbolique ref. Si ref n'est pas une référence symbolique, retourne une chaîne vide.

features()

Renvoie une liste des fonctionnalités git que la version actuelle de libgit2 prend en charge, telles que le multithreading ou l'utilisation de HTTPS ou SSH.

filename(te::GitTreeEntry)

Retourne le nom de fichier de l'objet sur le disque auquel te fait référence.

filemode(te::GitTreeEntry) -> Cint

Retourne le mode de fichier UNIX de l'objet sur le disque auquel te fait référence sous forme d'entier.

LibGit2.gitdir(repo::GitRepo)

Retourne l'emplacement des fichiers "git" de repo :

• pour les dépôts normaux, c'est l'emplacement du dossier .git.
• pour les dépôts nus, c'est l'emplacement du dépôt lui-même.

Voir aussi workdir, path.

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

Créez une chaîne basée sur les composants d'URL fournis. Lorsque le mot-clé scheme n'est pas fourni, l'URL produite utilisera la syntaxe scp-like alternative.

Mots-clés

• scheme::AbstractString="": le schéma d'URL qui identifie le protocole à utiliser. Pour HTTP, utilisez "http", pour SSH, utilisez "ssh", etc. Lorsque scheme n'est pas fourni, le format de sortie sera "ssh" mais en utilisant la syntaxe scp-like.
• username::AbstractString="": le nom d'utilisateur à utiliser dans la sortie si fourni.
• password::AbstractString="": le mot de passe à utiliser dans la sortie si fourni.
• host::AbstractString="": le nom d'hôte à utiliser dans la sortie. Un nom d'hôte doit être spécifié.
• port::Union{AbstractString,Integer}="": le numéro de port à utiliser dans la sortie si fourni. Ne peut pas être spécifié lors de l'utilisation de la syntaxe scp-like.
• path::AbstractString="": le chemin à utiliser dans la sortie si fourni.

Exemples

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

Construit un objet de hachage git à partir de la chaîne donnée, retournant un GitShortHash si la chaîne est plus courte que 40 chiffres hexadécimaux, sinon un GitHash.

Exemples

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

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

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

Renvoie un GitReference vers le HEAD actuel de repo.

head(pkg::AbstractString) -> String

Renvoie le HEAD actuel GitHash du dépôt pkg sous forme de chaîne.

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

Définit le HEAD de repo sur l'objet pointé par ref.

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

Recherchez l'identifiant de l'objet du HEAD actuel du dépôt git repo.

LibGit2.headname(repo::GitRepo)

Recherchez le nom du HEAD actuel du dépôt git repo. Si repo est actuellement détaché, renvoyez le nom du HEAD dont il est détaché.

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

Ouvre un nouveau dépôt git à path. Si bare est false, l'arborescence de travail sera créée dans path/.git. Si bare est true, aucun répertoire de travail ne sera créé.

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

Retourne true si a, un GitHash sous forme de chaîne, est un ancêtre de b, un GitHash sous forme de chaîne.

Exemples

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

Utilisez une heuristique pour deviner si un fichier est binaire : rechercher des octets NULL et examiner un rapport raisonnable de caractères imprimables à non imprimables parmi les 8000 premiers octets.

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

Vérifiez si le commit id (qui est un GitHash sous forme de chaîne) est dans le dépôt.

Exemples

julia> repo = GitRepo(repo_path);

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

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

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

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

Vérifie s'il existe des différences entre l'arbre spécifié par treeish et les fichiers suivis dans l'arbre de travail (si cached=false) ou l'index (si cached=true). pathspecs sont les spécifications pour les options du diff.

Exemples

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdiff(repo, "HEAD") # devrait être faux
open(joinpath(repo_path, new_file), "a") do f
    println(f, "voici mon nouveau fichier génial")
end
LibGit2.isdiff(repo, "HEAD") # maintenant vrai

Équivalent à git diff-index <treeish> [-- <pathspecs>].

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

Vérifiez s'il y a eu des modifications dans les fichiers suivis dans l'arbre de travail (si cached=false) ou dans l'index (si cached=true). pathspecs sont les spécifications pour les options du diff.

Exemples

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdirty(repo) # devrait être faux
open(joinpath(repo_path, new_file), "a") do f
    println(f, "voici mon nouveau fichier génial")
end
LibGit2.isdirty(repo) # maintenant vrai
LibGit2.isdirty(repo, new_file) # maintenant vrai

Équivalent à git diff-index HEAD [-- <pathspecs>]. ```

LibGit2.isorphan(repo::GitRepo)

Vérifiez si la branche actuelle est une branche "orpheline", c'est-à-dire qu'elle n'a pas de commits. Le premier commit de cette branche n'aura pas de parents.

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

Testez si les bits de val indexés par flag sont définis (1) ou non définis (0).

iszero(id::GitHash) -> Bool

Déterminez si tous les chiffres hexadécimaux du GitHash donné sont zéro.

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

Déterminez si la branche spécifiée par branch_name existe dans le dépôt repo. Si remote est true, repo est supposé être un dépôt git distant. Sinon, il fait partie du système de fichiers local.

Retournez soit une GitReference vers la branche demandée si elle existe, soit nothing si ce n'est pas le cas.

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

En utilisant le GitRevWalker walker pour "parcourir" chaque commit dans l'historique du dépôt, appliquez f à chaque commit dans le parcours. Les arguments clés sont : * oid : Le GitHash du commit à partir duquel commencer le parcours. La valeur par défaut est d'utiliser push_head! et donc le commit HEAD et tous ses ancêtres. * range : Une plage de GitHashs au format oid1..oid2. f sera appliqué à tous les commits entre les deux. * by : La méthode de tri. La valeur par défaut est de ne pas trier. D'autres options consistent à trier par topologie (LibGit2.Consts.SORT_TOPOLOGICAL), à trier dans le temps (LibGit2.Consts.SORT_TIME, le plus ancien en premier) ou à trier à l'envers dans le temps (LibGit2.Consts.SORT_REVERSE, le plus récent en premier). * rev : Indique si l'ordre trié doit être inversé (par exemple, si le tri topologique est utilisé).

Exemples

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

Ici, LibGit2.map visite chaque commit en utilisant le GitRevWalker et trouve son GitHash.

Fonction de rappel miroir

La fonction définit les refspecs +refs/*:refs/* et le drapeau mirror pour la référence distante.

Pointeur de fonction C pour mirror_callback

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

Retourne le message de commit décrivant les changements effectués dans le commit c. Si raw est false, retourne un message légèrement "nettoyé" (qui a toutes les nouvelles lignes en tête supprimées). Si raw est true, le message n'est pas dépouillé de ces nouvelles lignes.

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

Exécutez l'analyse sur les branches pointées par les extrémités de branche annotées anns et déterminez dans quelles circonstances elles peuvent être fusionnées. Par exemple, si anns[1] est simplement un ancêtre de ann[2], alors merge_analysis rapportera qu'une fusion par avance rapide est possible.

Retournez deux sorties, analysis et preference. analysis a plusieurs valeurs possibles : * MERGE_ANALYSIS_NONE : il n'est pas possible de fusionner les éléments de anns. * MERGE_ANALYSIS_NORMAL : une fusion normale, lorsque HEAD et les commits que l'utilisateur souhaite fusionner ont tous divergé d'un ancêtre commun. Dans ce cas, les changements doivent être résolus et des conflits peuvent survenir. * MERGE_ANALYSIS_UP_TO_DATE : tous les commits d'entrée que l'utilisateur souhaite fusionner peuvent être atteints depuis HEAD, donc aucune fusion n'a besoin d'être effectuée. * MERGE_ANALYSIS_FASTFORWARD : le commit d'entrée est un descendant de HEAD et donc aucune fusion n'a besoin d'être effectuée - au lieu de cela, l'utilisateur peut simplement vérifier le(s) commit(s) d'entrée. * MERGE_ANALYSIS_UNBORN : le HEAD du dépôt fait référence à un commit qui n'existe pas. Il n'est pas possible de fusionner, mais il peut être possible de vérifier les commits d'entrée. preference a également plusieurs valeurs possibles : * MERGE_PREFERENCE_NONE : l'utilisateur n'a pas de préférence. * MERGE_PREFERENCE_NO_FASTFORWARD : ne pas autoriser les fusions par avance rapide. * MERGE_PREFERENCE_FASTFORWARD_ONLY : autoriser uniquement les fusions par avance rapide et aucun autre type (ce qui peut introduire des conflits). preference peut être contrôlé par la configuration git du dépôt ou globale.

LibGit2.name(ref::GitReference)

Retourne le nom complet de ref.

name(rmt::GitRemote)

Obtenez le nom d'un dépôt distant, par exemple "origin". Si le dépôt distant est anonyme (voir GitRemoteAnon), le nom sera une chaîne vide "".

Exemples

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)

Le nom de tag (par exemple, "v0.5").

need_update(repo::GitRepo)

Équivalent à git update-index. Retourne true si repo a besoin d'être mis à jour.

objtype(obj_type::Consts.OBJECT)

Renvoie le type correspondant à la valeur de l'énumération.

LibGit2.path(repo::GitRepo)

Retourne le chemin de base du fichier du dépôt repo.

• pour les dépôts normaux, cela sera généralement le répertoire parent du répertoire ".git" (note : cela peut être différent du répertoire de travail, voir workdir pour plus de détails).
• pour les dépôts nus, c'est l'emplacement des fichiers "git".

Voir aussi gitdir, workdir.

peel([T,] ref::GitReference)

Peler récursivement ref jusqu'à obtenir un objet de type T. Si aucun T n'est fourni, alors ref sera pelé jusqu'à obtenir un objet autre qu'un GitTag.

• Un GitTag sera pelé vers l'objet qu'il référence.
• Un GitCommit sera pelé vers un GitTree.

peel([T,] obj::GitObject)

Peler récursivement obj jusqu'à ce qu'un objet de type T soit obtenu. Si aucun T n'est fourni, alors obj sera pelé jusqu'à ce que le type change.

• Un GitTag sera pelé vers l'objet qu'il référence.
• Un GitCommit sera pelé vers un GitTree.

LibGit2.posixpath(path)

Standardiser la chaîne de chemin path pour utiliser des séparateurs POSIX.

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

Poussez vers le dépôt git distant rmt spécifié, en utilisant refspecs pour déterminer quelle(s) branche(s) distante(s) pousser. Les arguments clés sont :

• force : si true, un push forcé se produira, ignorant les conflits.
• options : détermine les options pour le push, par exemple, quels en-têtes de proxy utiliser. Voir PushOptions pour plus d'informations.

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

Pousse les mises à jour vers un upstream de repo.

Les arguments clés sont :

• remote::AbstractString="origin" : le nom du remote upstream vers lequel pousser.
• remoteurl::AbstractString="" : l'URL de remote.
• refspecs=AbstractString[] : détermine les propriétés de la poussée.
• force::Bool=false : détermine si la poussée sera une poussée forcée, écrasant la branche distante.
• credentials=nothing : fournit des identifiants et/ou des paramètres lors de l'authentification contre un remote privé.
• callbacks=Callbacks() : rappels et charges utiles fournis par l'utilisateur.

Équivalent à git push [<remoteurl>|<repo>] [<refspecs>].

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

Commencez le GitRevWalker walker au commit cid. Cette fonction peut être utilisée pour appliquer une fonction à tous les commits depuis une certaine année, en passant le premier commit de cette année comme cid et en passant ensuite le w résultant à LibGit2.map.

LibGit2.push_head!(w::GitRevWalker)

Poussez le commit HEAD et ses ancêtres sur le GitRevWalker w. Cela garantit que HEAD et tous ses commits ancêtres seront rencontrés lors de la marche.

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

Obtenez les push refspecs pour le rmt spécifié. Ces refspecs contiennent des informations sur quelle(s) branche(s) pousser.

Exemples

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}

Obtenez les octets bruts du GitHash sous forme de vecteur de longueur 20.

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

Lire l'arbre tree (ou l'arbre pointé par treehash dans le dépôt appartenant à idx) dans l'index idx. Le contenu actuel de l'index sera remplacé.

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

Tentez un rebase de fusion automatique de la branche actuelle, à partir de upstream si fourni, ou sinon à partir de la branche de suivi en amont. newbase est la branche sur laquelle faire le rebase. Par défaut, c'est upstream.

Si des conflits surviennent qui ne peuvent pas être résolus automatiquement, le rebase sera annulé, laissant le dépôt et l'arbre de travail dans leur état d'origine, et la fonction lancera une GitError. Cela équivaut à peu près à l'instruction de ligne de commande suivante :

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

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

Obtenez une liste de tous les noms de référence dans le dépôt repo.

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

Retourne un Cint correspondant au type de ref :

• 0 si la référence est invalide
• 1 si la référence est un identifiant d'objet
• 2 si la référence est symbolique

LibGit2.remotes(repo::GitRepo)

Renvoie un vecteur des noms des télécommandes de repo.

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

Supprime tous les fichiers dont les chemins sont spécifiés par files dans l'index idx (ou l'index du repo).

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

Réinitialise les bits de val indexés par flag, les renvoyant à 0.

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

Réinitialise l'état du payload aux valeurs initiales afin qu'il puisse être utilisé à nouveau dans le rappel d'identification. Si une config est fournie, la configuration sera également mise à jour.

Met à jour certaines entrées, déterminées par les pathspecs, dans l'index à partir de l'arbre de commit cible.

Définit le HEAD actuel sur l'oid de commit spécifié et réinitialise éventuellement l'index et l'arbre de travail pour correspondre.

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

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

Réinitialisez le dépôt repo à son état à id, en utilisant l'un des trois modes définis par mode :

1. Consts.RESET_SOFT - déplacez HEAD vers id.
2. Consts.RESET_MIXED - par défaut, déplacez HEAD vers id et réinitialisez l'index à id.
3. Consts.RESET_HARD - déplacez HEAD vers id, réinitialisez l'index à id, et abandonnez tous les changements en cours.

Exemples

# récupérer les changements
LibGit2.fetch(repo)
isfile(joinpath(repo_path, our_file)) # sera faux

# fusion rapide des changements
LibGit2.merge!(repo, fastforward=true)

# parce qu'il n'y avait pas de fichier localement, mais qu'il y a
# un fichier à distance, nous devons réinitialiser la branche
head_oid = LibGit2.head_oid(repo)
new_head = LibGit2.reset!(repo, head_oid, LibGit2.Consts.RESET_HARD)

Dans cet exemple, le dépôt à partir duquel nous récupérons a un fichier appelé our_file dans son index, c'est pourquoi nous devons réinitialiser.

Équivalent à git reset [--soft | --mixed | --hard] <id>.

Exemples

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
# va abandonner les changements dans file1
# et le désindexer
new_head = LibGit2.reset!(repo, head_oid, mode)

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

Restaurez un dépôt repo à un État s précédent, par exemple le HEAD d'une branche avant une tentative de fusion. s peut être généré en utilisant la fonction snapshot.

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

Liste le nombre de révisions entre commit1 et commit2 (OIDs de commit sous forme de chaîne). Étant donné que commit1 et commit2 peuvent être sur des branches différentes, revcount effectue une liste de révisions "gauche-droite" (et un compte), retournant un tuple d'Ints - le nombre de commits à gauche et à droite, respectivement. Un commit à gauche (ou à droite) fait référence à quel côté d'une différence symétrique dans un arbre le commit est accessible.

Équivalent à git rev-list --left-right --count <commit1> <commit2>.

Exemples

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

Cela retournera (-1, 0).

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

Définir à la fois l'url de récupération et de poussée pour remote_name pour le GitRepo ou le dépôt git situé à path. En général, les dépôts git utilisent "origin" comme nom distant.

Exemples

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)

Renvoie une version abrégée du nom de ref qui est "lisible par un humain".

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

Prenez un instantané de l'état actuel du dépôt repo, en stockant le HEAD actuel, l'index et tout travail non validé. La sortie State peut être utilisée plus tard lors d'un appel à restore pour ramener le dépôt à l'état instantané.

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

Décomposez le ConfigEntry en les éléments suivants : section, sous-section, nom et valeur.

Exemples

Étant donné le fichier de configuration git contenant :

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

Le ConfigEntry ressemblerait à ceci :

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

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

Consultez la documentation de la syntaxe de la configuration git pour plus de détails. ```

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

Vérifiez le statut du fichier à path dans le dépôt git repo. Par exemple, cela peut être utilisé pour vérifier si le fichier à path a été modifié et doit être mis en scène et engagé.

stage(ie::IndexEntry) -> Cint

Obtenez le numéro de stage de ie. Le numéro de stage 0 représente l'état actuel de l'arbre de travail, mais d'autres numéros peuvent être utilisés en cas de conflit de fusion. Dans ce cas, les différents numéros de stage sur un IndexEntry décrivent à quel(x) côté(s) du conflit l'état actuel du fichier appartient. Le stage 0 est l'état avant la tentative de fusion, le stage 1 est les modifications qui ont été apportées localement, les stages 2 et supérieurs sont pour les modifications provenant d'autres branches (par exemple, dans le cas d'une fusion "octopus" multi-branches, les stages 2, 3 et 4 pourraient être utilisés).

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

Créez un nouveau tag git tag (par exemple, "v0.5") dans le dépôt repo, au commit commit.

Les arguments de mot-clé sont :

• msg::AbstractString="": le message pour le tag.
• force::Bool=false: si true, les références existantes seront écrasées.
• sig::Signature=Signature(repo): la signature du tagueur.

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

Supprimez le tag git tag du dépôt repo.

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

Obtenez une liste de tous les tags dans le dépôt git repo.

LibGit2.target(tag::GitTag)

Le GitHash de l'objet cible de tag.

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

Inversez les bits de val indexés par flag, de sorte que si un bit est 0, il sera 1 après l'inversion, et vice-versa.

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

Appliquez la fonction f au dépôt git repo, en prenant un snapshot avant d'appliquer f. Si une erreur se produit dans f, repo sera restauré à son état de snapshot en utilisant restore. L'erreur qui s'est produite sera relancée, mais l'état de repo ne sera pas corrompu.

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

Parcourt les entrées dans tree et ses sous-arbres en ordre post ou pré. L'ordre pré signifie commencer à la racine, puis parcourir le sous-arbre le plus à gauche (et récursivement à travers les sous-arbres les plus à gauche de ce sous-arbre) et se déplacer vers la droite à travers les sous-arbres. L'ordre post signifie commencer par le bas du sous-arbre le plus à gauche, remonter à travers celui-ci, puis parcourir le sous-arbre de droite suivant (encore une fois en commençant par le bas) et enfin visiter la racine de l'arbre en dernier.

Le paramètre de fonction f doit avoir la signature suivante :

(String, GitTreeEntry) -> Cint

Une valeur négative retournée par f arrête le parcours de l'arbre. Une valeur positive signifie que l'entrée sera ignorée si post est false.

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

Déterminez si la branche contenant ref a une branche amont spécifiée.

Retournez soit un GitReference vers la branche amont si elle existe, soit nothing si la branche demandée n'a pas de contrepartie amont.

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

Met à jour tous les fichiers dont les chemins sont spécifiés par files dans l'index idx (ou l'index du repo). Fait correspondre l'état de chaque fichier dans l'index avec l'état actuel sur le disque, en le supprimant s'il a été supprimé sur le disque, ou en mettant à jour son entrée dans la base de données d'objets.

url(rmt::GitRemote)

Obtenez l'URL de récupération d'un dépôt git distant.

Exemples

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

Retourne la version de libgit2 utilisée, sous la forme d'un VersionNumber.

with(f::Function, obj)

Fonction d'aide à la gestion des ressources. Applique f à obj, en s'assurant d'appeler close sur obj après que f ait réussi à retourner ou ait levé une erreur. Garantit que les ressources git allouées sont finalisées dès qu'elles ne sont plus nécessaires.

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

Fonction d'aide à la gestion des ressources. Applique f à args, en construisant d'abord une instance de type T à partir de args. S'assure d'appeler close sur l'objet résultant après que f ait réussi à retourner ou ait levé une erreur. Garantit que les ressources git allouées sont finalisées dès qu'elles ne sont plus nécessaires. Si une erreur est levée par f, un avertissement est affiché contenant l'erreur.

LibGit2.workdir(repo::GitRepo)

Renvoie l'emplacement du répertoire de travail de repo. Cela générera une erreur pour les dépôts nus.

Voir aussi gitdir, path.

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

Obtenez l'objet git auquel te fait référence et renvoyez-le sous son type réel (le type entrytype montrerait), par exemple un GitBlob ou un GitTag.

Exemples

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

Credential qui ne prennent en charge que les paramètres user et password

Type de credential SSH

isfilled(cred::AbstractCredential) -> Bool

Vérifie qu'un credential est prêt à être utilisé pour l'authentification.

Met en cache les informations d'identification pour réutilisation

LibGit2.CredentialPayload

Conserve l'état entre plusieurs appels à la fonction de rappel d'identification pour la même URL. Une instance de CredentialPayload doit être reset! chaque fois qu'elle sera utilisée avec une URL différente.

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

Stocker le payload d'identification pour une réutilisation lors d'une future authentification. Ne doit être appelé que lorsque l'authentification a réussi.

Le mot-clé shred contrôle si les informations sensibles dans le champ d'identification du payload doivent être détruites. Ne doit être défini sur false que lors des tests.

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

Rejeter le credential payload afin qu'il ne soit pas réutilisé lors de futures authentifications. Ne doit être appelé que lorsque l'authentification a échoué.

Le mot-clé shred contrôle si les informations sensibles dans le champ de credential du payload doivent être détruites. Ne doit être défini sur false que lors des tests.

Niveau de priorité d'un fichier de configuration.

Ces niveaux de priorité correspondent à la logique d'escalade naturelle (de plus élevé à plus bas) lors de la recherche d'entrées de configuration dans git.

• CONFIG_LEVEL_DEFAULT - Ouvrir les fichiers de configuration globaux, XDG et système s'ils sont disponibles.
• CONFIG_LEVEL_PROGRAMDATA - Système entier sur Windows, pour la compatibilité avec git portable
• CONFIG_LEVEL_SYSTEM - Fichier de configuration système ; /etc/gitconfig sur les systèmes Linux
• CONFIG_LEVEL_XDG - Fichier de configuration compatible XDG ; typiquement ~/.config/git/config
• CONFIG_LEVEL_GLOBAL - Fichier de configuration spécifique à l'utilisateur (également appelé fichier de configuration global) ; typiquement ~/.gitconfig
• CONFIG_LEVEL_LOCAL - Fichier de configuration spécifique au dépôt ; $WORK_DIR/.git/config sur les dépôts non nus
• CONFIG_LEVEL_APP - Fichier de configuration spécifique à l'application ; librement défini par les applications
• CONFIG_HIGHEST_LEVEL - Représente le fichier de configuration disponible au niveau le plus élevé (c'est-à-dire le fichier de configuration le plus spécifique disponible qui est effectivement chargé)