LibGit2

LibGit2.Buffer

Un búfer de datos para exportar datos de libgit2. Coincide con la estructura git_buf.

Al obtener datos de LibGit2, un uso típico se vería así:

buf_ref = Ref(Buffer())
@check ccall(..., (Ptr{Buffer},), buf_ref)
# operación sobre buf_ref
free(buf_ref)

En particular, tenga en cuenta que LibGit2.free debe ser llamado después sobre el objeto Ref.

LibGit2.CheckoutOptions

Coincide con la estructura git_checkout_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• checkout_strategy: determina cómo manejar los conflictos y si forzar la checkout/recrear archivos faltantes.
• disable_filters: si es distinto de cero, no aplicar filtros como CLRF (para convertir los saltos de línea de archivos entre UNIX y DOS).
• dir_mode: modo de lectura/escritura/acceso para cualquier directorio involucrado en la checkout. El valor predeterminado es 0755.
• file_mode: modo de lectura/escritura/acceso para cualquier archivo involucrado en la checkout. El valor predeterminado es 0755 o 0644, dependiendo del blob.
• file_open_flags: banderas de bits utilizadas para abrir cualquier archivo durante la checkout.
• notify_flags: Banderas sobre qué tipo de conflictos se debe notificar al usuario.
• notify_cb: Una función de callback opcional para notificar al usuario si ocurre un conflicto de checkout. Si esta función devuelve un valor distinto de cero, la checkout será cancelada.
• notify_payload: Carga útil para la función de callback de notificación.
• progress_cb: Una función de callback opcional para mostrar el progreso de la checkout.
• progress_payload: Carga útil para el callback de progreso.
• paths: Si no está vacío, describe qué rutas buscar durante la checkout. Si está vacío, la checkout ocurrirá sobre todos los archivos en el repositorio.
• baseline: Contenido esperado del workdir, capturado en un (puntero a un) GitTree. Por defecto, es el estado del árbol en HEAD.
• baseline_index: Contenido esperado del workdir, capturado en un (puntero a un) GitIndex. Por defecto, es el estado del índice en HEAD.
• target_directory: Si no está vacío, checkout a este directorio en lugar del workdir.
• ancestor_label: En caso de conflictos, el nombre del lado del ancestro común.
• our_label: En caso de conflictos, el nombre de "nuestro" lado.
• their_label: En caso de conflictos, el nombre de "su" lado.
• perfdata_cb: Una función de callback opcional para mostrar datos de rendimiento.
• perfdata_payload: Carga útil para el callback de rendimiento.

LibGit2.CloneOptions

Coincide con la estructura git_clone_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• checkout_opts: Las opciones para realizar el checkout del remoto como parte de la clonación.
• fetch_opts: Las opciones para realizar la obtención previa al checkout del remoto como parte de la clonación.
• bare: Si 0, clona el repositorio remoto completo. Si es diferente de cero, realiza una clonación bare, en la que no hay una copia local de los archivos fuente en el repositorio y el gitdir y workdir son los mismos.
• localclone: Indicador de si clonar una base de datos de objetos local o hacer una obtención. El valor predeterminado es dejar que git decida. No utilizará el transporte consciente de git para una clonación local, pero lo usará para URLs que comienzan con file://.
• checkout_branch: El nombre de la rama a la que hacer checkout. Si es una cadena vacía, se hará checkout de la rama predeterminada del remoto.
• repository_cb: Un callback opcional que se utilizará para crear el nuevo repositorio en el que se realiza la clonación.
• repository_cb_payload: La carga útil para el callback del repositorio.
• remote_cb: Un callback opcional utilizado para crear el GitRemote antes de hacer la clonación desde él.
• remote_cb_payload: La carga útil para el callback remoto.

LibGit2.DescribeOptions

Coincide con la estructura git_describe_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• max_candidates_tags: considera este número de las etiquetas más recientes en refs/tags para describir un commit. Por defecto es 10 (por lo que se examinarían las 10 etiquetas más recientes para ver si describen un commit).
• describe_strategy: si considerar todas las entradas en refs/tags (equivalente a git-describe --tags) o todas las entradas en refs/ (equivalente a git-describe --all). El valor predeterminado es mostrar solo etiquetas anotadas. Si se pasa Consts.DESCRIBE_TAGS, se considerarán todas las etiquetas, anotadas o no. Si se pasa Consts.DESCRIBE_ALL, se considerará cualquier ref en refs/.
• pattern: solo considera etiquetas que coincidan con pattern. Soporta expansión glob.
• only_follow_first_parent: al encontrar la distancia desde una referencia coincidente al objeto descrito, solo considera la distancia desde el primer padre.
• show_commit_oid_as_fallback: si no se puede encontrar una referencia coincidente que describa un commit, muestra el GitHash del commit en lugar de lanzar un error (el comportamiento predeterminado).

LibGit2.DescribeFormatOptions

Coincide con la estructura git_describe_format_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• abbreviated_size: límite inferior en el tamaño del GitHash abreviado a utilizar, que por defecto es 7.
• always_use_long_format: establecer en 1 para usar el formato largo para cadenas incluso si se puede usar un formato corto.
• dirty_suffix: si se establece, esto se añadirá al final de la cadena de descripción si el workdir está sucio.

LibGit2.DiffDelta

Descripción de los cambios en una entrada. Coincide con la estructura git_diff_delta.

Los campos representan:

• status: Uno de Consts.DELTA_STATUS, que indica si el archivo ha sido agregado/modificado/eliminado.
• flags: Banderas para el delta y los objetos en cada lado. Determina si tratar los archivos como binarios/texto, si existen en cada lado del diff, y si se sabe que los ids de los objetos son correctos.
• similarity: Se utiliza para indicar si un archivo ha sido renombrado o copiado.
• nfiles: El número de archivos en el delta (por ejemplo, si el delta se ejecutó en un id de commit de submódulo, puede contener más de un archivo).
• old_file: Un DiffFile que contiene información sobre el/los archivo(s) antes de los cambios.
• new_file: Un DiffFile que contiene información sobre el/los archivo(s) después de los cambios.

LibGit2.DiffFile

Descripción de un lado de un delta. Coincide con la estructura git_diff_file.

Los campos representan:

• id: el GitHash del elemento en la diferencia. Si el elemento está vacío en este lado de la diferencia (por ejemplo, si la diferencia es de la eliminación de un archivo), esto será GitHash(0).
• path: una ruta terminada en NULL al elemento relativa al directorio de trabajo del repositorio.
• size: el tamaño del elemento en bytes.
• flags: una combinación de las banderas git_diff_flag_t. El bit i de este entero establece la bandera i.
• mode: el modo stat para el elemento.
• id_abbrev: solo presente en versiones de LibGit2 más nuevas o iguales a 0.25.0. La longitud del campo id cuando se convierte usando string. Generalmente igual a OID_HEXSZ (40).

LibGit2.DiffOptionsStruct

Coincide con la estructura git_diff_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• flags: banderas que controlan qué archivos aparecerán en la diferencia. Por defecto es DIFF_NORMAL.
• ignore_submodules: si se deben considerar los archivos en submódulos o no. Por defecto es SUBMODULE_IGNORE_UNSPECIFIED, lo que significa que la configuración del submódulo controlará si aparece en la diferencia o no.
• pathspec: ruta a los archivos que se incluirán en la diferencia. El valor por defecto es usar todos los archivos en el repositorio.
• notify_cb: callback opcional que notificará al usuario sobre cambios en la diferencia a medida que se agreguen deltas de archivos.
• progress_cb: callback opcional que mostrará el progreso de la diferencia. Solo es relevante en versiones de libgit2 al menos tan nuevas como 0.24.0.
• payload: la carga útil que se pasará a notify_cb y progress_cb.
• context_lines: el número de líneas sin cambios utilizadas para definir los bordes de un hunk. Este también es el número de líneas que se mostrarán antes/después de un hunk para proporcionar contexto. El valor por defecto es 3.
• interhunk_lines: el número máximo de líneas sin cambios entre dos hunks separados permitidos antes de que los hunks se combinen. El valor por defecto es 0.
• id_abbrev: establece la longitud del GitHash abreviado a imprimir. El valor por defecto es 7.
• max_size: el tamaño máximo de archivo de un blob. Por encima de este tamaño, se tratará como un blob binario. El valor por defecto es 512 MB.
• old_prefix: el directorio de archivos virtual en el que colocar archivos antiguos en un lado de la diferencia. El valor por defecto es "a".
• new_prefix: el directorio de archivos virtual en el que colocar archivos nuevos en un lado de la diferencia. El valor por defecto es "b".

LibGit2.FetchHead

Contiene la información sobre HEAD durante una recuperación, incluyendo el nombre y la URL de la rama de la que se recuperó, el oid del HEAD y si el HEAD recuperado ha sido fusionado localmente.

Los campos representan:

• name: El nombre en la base de datos de referencias local del head de recuperación, por ejemplo, "refs/heads/master".
• url: La URL del head de recuperación.
• oid: El GitHash de la punta del head de recuperación.
• ismerge: Bandera booleana que indica si los cambios en el remoto han sido fusionados en la copia local o no. Si true, la copia local está actualizada con el head de recuperación remoto.

LibGit2.FetchOptions

Coincide con la estructura git_fetch_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• callbacks: callbacks remotos a utilizar durante la obtención.
• prune: si se debe realizar una poda después de la obtención o no. El valor predeterminado es usar la configuración del GitConfig.
• update_fetchhead: si se debe actualizar el FetchHead después de la obtención. El valor predeterminado es realizar la actualización, que es el comportamiento normal de git.
• download_tags: si se deben descargar las etiquetas presentes en el remoto o no. El valor predeterminado es solicitar las etiquetas para los objetos que se están descargando de todos modos desde el servidor.
• proxy_opts: opciones para conectarse al remoto a través de un proxy. Ver ProxyOptions. Solo presente en versiones de libgit2 más nuevas o iguales a 0.25.0.
• custom_headers: cualquier encabezado adicional necesario para la obtención. Solo presente en versiones de libgit2 más nuevas o iguales a 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 anotado lleva consigo información sobre cómo fue buscado y por qué, de modo que las operaciones de rebase o merge tengan más información sobre el contexto del commit. Los archivos de conflicto contienen información sobre las ramas de origen/destino en el merge que están en conflicto, por ejemplo. Un commit anotado puede referirse a la punta de una rama remota, por ejemplo, cuando se pasa un FetchHead, o a una cabeza de rama descrita usando GitReference.

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

Construye un objeto GitBlame para el archivo en path, utilizando información de cambios obtenida de la historia de repo. El objeto GitBlame registra quién cambió qué partes del archivo, cuándo y cómo. options controla cómo separar el contenido del archivo y qué commits investigar - consulta BlameOptions para más información.

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

Devuelve un objeto GitBlob de repo especificado por hash/spec.

• hash es un hash completo (GitHash) o parcial (GitShortHash).
• spec es una especificación textual: consulta la documentación de git para una lista completa.

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

Devuelve un objeto GitCommit de repo especificado por hash/spec.

• hash es un hash completo (GitHash) o parcial (GitShortHash).
• spec es una especificación textual: consulta la documentación de git para una lista completa.

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

Crea un nuevo GitConfig cargando la información de configuración desde el archivo en path. Consulta addfile para más información sobre las opciones level, repo y force.

GitConfig(repo::GitRepo)

Obtiene la configuración almacenada para el repositorio git repo. Si repo no tiene un archivo de configuración específico establecido, se utilizará la configuración git predeterminada.

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

Obtén la configuración git predeterminada cargando los archivos de configuración global y del sistema en una configuración priorizada. Esto se puede usar para acceder a las opciones de configuración predeterminadas fuera de un repositorio git específico.

GitHash

Un identificador de objeto git, basado en el hash sha-1. Es una cadena de 20 bytes (40 dígitos hexadecimales) utilizada para identificar un GitObject en un repositorio.

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

Devuelve el objeto especificado (GitCommit, GitBlob, GitTree o GitTag) de repo especificado por hash/spec.

• hash es un hash completo (GitHash) o parcial (GitShortHash).
• spec es una especificación textual: consulta la documentación de git para una lista completa.

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

Busca un repositorio git remoto utilizando su nombre y URL. Utiliza el refspec de fetch por defecto.

Ejemplos

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

Busca un repositorio git remoto utilizando el nombre y la URL del repositorio, así como especificaciones sobre cómo obtener del remoto (por ejemplo, qué rama remota obtener).

Ejemplos

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

Busca un repositorio git remoto utilizando solo su URL, no su nombre.

Ejemplos

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

LibGit2.GitRepo(path::AbstractString)

Abre un repositorio git en path.

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

Abre un repositorio git en path con controles extendidos (por ejemplo, si el usuario actual debe ser miembro de un grupo de acceso especial para leer path).

GitRevWalker(repo::GitRepo)

Un GitRevWalker camina a través de las revisiones (es decir, commits) de un repositorio git repo. Es una colección de los commits en el repositorio, y soporta iteración y llamadas a LibGit2.map y LibGit2.count (por ejemplo, LibGit2.count podría usarse para determinar qué porcentaje de commits en un repositorio fueron realizados por un cierto autor).

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

Aquí, LibGit2.count encuentra el número de commits a lo largo del recorrido con un cierto GitHash. Dado que el GitHash es único para un commit, cnt será 1.

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

Un identificador de objeto git abreviado, que se puede utilizar para identificar un objeto git cuando es único, que consiste en los primeros len dígitos hexadecimales de hash (los dígitos restantes se ignoran).

LibGit2.GitSignature

Este es un envoltorio de Julia alrededor de un puntero a un objeto git_signature.

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

Recopila información sobre el estado de cada archivo en el repositorio git repo (por ejemplo, si el archivo está modificado, preparado, etc.). status_opts se puede usar para establecer varias opciones, por ejemplo, si se debe o no mirar archivos no rastreados o si se deben incluir submódulos o no. Consulta StatusOptions para más información.

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

Devuelve un objeto GitTag de repo especificado por hash/spec.

• hash es un hash completo (GitHash) o parcial (GitShortHash).
• spec es una especificación textual: consulta la documentación de git para una lista completa.

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

Devuelve un objeto GitTree de repo especificado por hash/spec.

• hash es un hash completo (GitHash) o parcial (GitShortHash).
• spec es una especificación textual: consulta la documentación de git para una lista completa.

LibGit2.IndexEntry

Representación en memoria de una entrada de archivo en el índice. Coincide con la estructura git_index_entry.

LibGit2.IndexTime

Coincide con la estructura git_index_time.

LibGit2.BlameOptions

Coincide con la estructura git_blame_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• flags: uno de Consts.BLAME_NORMAL o Consts.BLAME_FIRST_PARENT (los otros flags de blame aún no están implementados por libgit2).
• min_match_characters: el número mínimo de caracteres alfanuméricos que deben cambiar en un commit para que el cambio se asocie con ese commit. El valor predeterminado es 20. Solo tiene efecto si se utiliza uno de los flags Consts.BLAME_*_COPIES, que libgit2 aún no implementa.
• newest_commit: el GitHash del commit más reciente desde el cual observar cambios.
• oldest_commit: el GitHash del commit más antiguo desde el cual observar cambios.
• min_line: la primera línea del archivo desde la cual comenzar a hacer blame. El valor predeterminado es 1.
• max_line: la última línea del archivo a la que hacer blame. El valor predeterminado es 0, lo que significa la última línea del archivo.

LibGit2.MergeOptions

Coincide con la estructura git_merge_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.

• flags: un enum para las banderas que describen el comportamiento de la fusión. Definido en git_merge_flag_t. El enum correspondiente en Julia es GIT_MERGE y tiene los valores:

  • MERGE_FIND_RENAMES: detectar si un archivo ha sido renombrado entre el ancestro común y el lado "nuestro" o "suyo" de la fusión. Permite fusiones donde un archivo ha sido renombrado.
  • MERGE_FAIL_ON_CONFLICT: salir inmediatamente si se encuentra un conflicto en lugar de intentar resolverlo.
  • MERGE_SKIP_REUC: no escribir la extensión REUC en el índice resultante de la fusión.
  • MERGE_NO_RECURSIVE: si los commits que se están fusionando tienen múltiples bases de fusión, usar la primera, en lugar de intentar fusionar recursivamente las bases.

• rename_threshold: cuán similares deben ser dos archivos para considerar uno como un renombramiento del otro. Este es un entero que establece el porcentaje de similitud. El valor predeterminado es 50.

• target_limit: el número máximo de archivos con los que comparar para buscar renombramientos. El valor predeterminado es 200.

• metric: función personalizada opcional para usar para determinar la similitud entre dos archivos para la detección de renombramientos.

• recursion_limit: el límite superior en el número de fusiones de ancestros comunes a realizar para intentar construir una nueva base de fusión virtual para la fusión. El valor predeterminado es sin límite. Este campo solo está presente en versiones de libgit2 más nuevas que 0.24.0.

• default_driver: el controlador de fusión a utilizar si ambos lados han cambiado. Este campo solo está presente en versiones de libgit2 más nuevas que 0.25.0.

• file_favor: cómo manejar los contenidos de archivos en conflicto para el controlador text.

  • MERGE_FILE_FAVOR_NORMAL: si ambos lados de la fusión tienen cambios en una sección, hacer una nota del conflicto en el índice que git checkout usará para crear un archivo de fusión, que el usuario puede luego referenciar para resolver los conflictos. Este es el valor predeterminado.
  • MERGE_FILE_FAVOR_OURS: si ambos lados de la fusión tienen cambios en una sección, usar la versión en el lado "nuestro" de la fusión en el índice.
  • MERGE_FILE_FAVOR_THEIRS: si ambos lados de la fusión tienen cambios en una sección, usar la versión en el lado "suyo" de la fusión en el índice.
  • MERGE_FILE_FAVOR_UNION: si ambos lados de la fusión tienen cambios en una sección, incluir cada línea única de ambos lados en el archivo que se coloca en el índice.

• file_flags: pautas para fusionar archivos.

LibGit2.ProxyOptions

Opciones para conectarse a través de un proxy.

Coincide con la estructura git_proxy_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.

• proxytype: un enum para el tipo de proxy a utilizar. Definido en git_proxy_t. El enum correspondiente en Julia es GIT_PROXY y tiene los valores:

  • PROXY_NONE: no intentar la conexión a través de un proxy.
  • PROXY_AUTO: intentar averiguar la configuración del proxy a partir de la configuración de git.
  • PROXY_SPECIFIED: conectarse utilizando la URL dada en el campo url de esta estructura.

  El valor predeterminado es detectar automáticamente el tipo de proxy.

• url: la URL del proxy.

• credential_cb: un puntero a una función de callback que se llamará si el remoto requiere autenticación para conectarse.

• certificate_cb: un puntero a una función de callback que se llamará si la verificación del certificado falla. Esto permite al usuario decidir si continuar o no con la conexión. Si la función devuelve 1, se permitirá la conexión. Si devuelve 0, no se permitirá la conexión. Se puede usar un valor negativo para devolver errores.

• payload: la carga útil que se proporcionará a las dos funciones de callback.

Ejemplos

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

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

LibGit2.PushOptions

Coincide con la estructura git_push_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• parallelism: si se debe crear un archivo de paquete, esta variable establece el número de hilos de trabajo que serán generados por el generador de paquetes. Si es 0, el generador de paquetes ajustará automáticamente el número de hilos a utilizar. El valor predeterminado es 1.
• callbacks: los callbacks (por ejemplo, para la autenticación con el remoto) que se utilizarán para el push.
• proxy_opts: solo relevante si la versión de LibGit2 es mayor o igual a 0.25.0. Establece opciones para usar un proxy para comunicarse con un remoto. Consulte ProxyOptions para más información.
• custom_headers: solo relevante si la versión de LibGit2 es mayor o igual a 0.24.0. Encabezados adicionales necesarios para la operación de push.

LibGit2.RebaseOperation

Describe una única instrucción/operación que se debe realizar durante el rebase. Coincide con la estructura git_rebase_operation.

Los campos representan:

• optype: el tipo de operación de rebase que se está realizando actualmente. Las opciones son:

  • REBASE_OPERATION_PICK: cherry-pick el commit en cuestión.
  • REBASE_OPERATION_REWORD: cherry-pick el commit en cuestión, pero reescribir su mensaje utilizando el aviso.
  • REBASE_OPERATION_EDIT: cherry-pick el commit en cuestión, pero permitir que el usuario edite el contenido del commit y su mensaje.
  • REBASE_OPERATION_SQUASH: aplastar el commit en cuestión en el commit anterior. Los mensajes de los dos commits se fusionarán.
  • REBASE_OPERATION_FIXUP: aplastar el commit en cuestión en el commit anterior. Solo se utilizará el mensaje del commit anterior.
  • REBASE_OPERATION_EXEC: no cherry-pick un commit. Ejecutar un comando y continuar si el comando se ejecuta con éxito.

• id: el GitHash del commit en el que se está trabajando durante este paso de rebase.

• exec: en caso de que se use REBASE_OPERATION_EXEC, el comando a ejecutar durante este paso (por ejemplo, ejecutar la suite de pruebas después de cada commit).

LibGit2.RebaseOptions

Coincide con la estructura git_rebase_options.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• quiet: informar a otros clientes de git que ayudan con/trabajan en el rebase que el rebase debe hacerse "silenciosamente". Utilizado para la interoperabilidad. El valor predeterminado es 1.
• inmemory: iniciar un rebase en memoria. Los llamadores que trabajan en el rebase pueden seguir sus pasos y confirmar cualquier cambio, pero no pueden retroceder HEAD ni actualizar el repositorio. El workdir no se modificará. Solo presente en versiones de libgit2 más nuevas o iguales a 0.24.0.
• rewrite_notes_ref: nombre de la referencia a notas que se utilizarán para reescribir las notas de confirmación a medida que se complete el rebase.
• merge_opts: opciones de fusión que controlan cómo se fusionarán los árboles en cada paso del rebase. Solo presente en versiones de libgit2 más nuevas o iguales a 0.24.0.
• checkout_opts: opciones de checkout para escribir archivos al inicializar el rebase, avanzar a través de él y abortarlo. Consulte CheckoutOptions para más información.

LibGit2.RemoteCallbacks

Configuraciones de callback. Coincide con la estructura git_remote_callbacks.

LibGit2.SignatureStruct

Una firma de acción (por ejemplo, para quienes hacen commits, etiquetadores, etc.). Coincide con la estructura git_signature.

Los campos representan:

• name: El nombre completo del autor o del que hace el commit.
• email: El correo electrónico al que se puede contactar al autor/commitente.
• when: una TimeStruct que indica cuándo se autoró/commitió el commit en el repositorio.

LibGit2.StatusEntry

Proporciona las diferencias entre el archivo tal como existe en HEAD y el índice, y proporciona las diferencias entre el índice y el directorio de trabajo. Coincide con la estructura git_status_entry.

Los campos representan:

• status: contiene las banderas de estado para el archivo, indicando si está actual o ha sido cambiado de alguna manera en el índice o en el árbol de trabajo.
• head_to_index: un puntero a un DiffDelta que encapsula la(s) diferencia(s) entre el archivo tal como existe en HEAD y en el índice.
• index_to_workdir: un puntero a un DiffDelta que encapsula la(s) diferencia(s) entre el archivo tal como existe en el índice y en el workdir.

LibGit2.StatusOptions

Opciones para controlar cómo git_status_foreach_ext() emitirá callbacks. Coincide con la estructura git_status_opt_t.

Los campos representan:

• version: versión de la estructura en uso, en caso de que esto cambie más adelante. Por ahora, siempre 1.
• show: una bandera para qué archivos examinar y en qué orden. El valor predeterminado es Consts.STATUS_SHOW_INDEX_AND_WORKDIR.
• flags: banderas para controlar cualquier callback utilizado en una llamada de estado.
• pathspec: un array de rutas a utilizar para la coincidencia de rutas. El comportamiento de la coincidencia de rutas variará dependiendo de los valores de show y flags.
• El baseline es el árbol que se utilizará para la comparación con el directorio de trabajo y el índice; por defecto es HEAD.

LibGit2.StrArrayStruct

Una representación de LibGit2 de un array de cadenas. Coincide con la estructura git_strarray.

Al obtener datos de LibGit2, un uso típico se vería así:

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

En particular, tenga en cuenta que LibGit2.free debe ser llamado después sobre el objeto Ref.

Por el contrario, al pasar un vector de cadenas a LibGit2, generalmente es más sencillo confiar en la conversión implícita:

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

Tenga en cuenta que no se requiere ninguna llamada a free ya que los datos son asignados por Julia.

LibGit2.TimeStruct

Tiempo en una firma. Coincide con la estructura git_time.

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

Agrega un archivo de configuración de git existente ubicado en path a la configuración GitConfig actual cfg. Si el archivo no existe, se creará.

• level establece el nivel de prioridad de la configuración de git y se determina por

Consts.GIT_CONFIG.

• repo es un repositorio opcional para permitir el análisis de inclusiones condicionales.
• Si force es false y ya existe una configuración para el nivel de prioridad dado,

addfile generará un error. Si force es true, la configuración existente será reemplazada por la que se encuentra en el archivo en path.

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

Agrega todos los archivos con rutas especificadas por files al índice idx (o al índice del repo). Si el archivo ya existe, la entrada del índice se actualizará. Si el archivo no existe ya, se añadirá nuevo al índice. files puede contener patrones glob que serán expandido y cualquier archivo que coincida será añadido (a menos que INDEX_ADD_DISABLE_PATHSPEC_MATCH esté configurado, ver más abajo). Si un archivo ha sido ignorado (en .gitignore o en la configuración), no se añadirá, a menos que ya esté siendo rastreado en el índice, en cuyo caso se actualizará. El argumento clave flags es un conjunto de banderas de bits que controlan el comportamiento con respecto a los archivos ignorados:

• Consts.INDEX_ADD_DEFAULT - por defecto, descrito arriba.
• Consts.INDEX_ADD_FORCE - desestimar las reglas de ignorar existentes y forzar la adición del archivo al índice incluso si ya está ignorado.
• Consts.INDEX_ADD_CHECK_PATHSPEC - no se puede usar al mismo tiempo que INDEX_ADD_FORCE. Verifica que cada archivo en files que existe en el disco no esté en la lista de ignorados. Si uno de los archivos está ignorado, la función devolverá EINVALIDSPEC.
• Consts.INDEX_ADD_DISABLE_PATHSPEC_MATCH - desactivar la coincidencia glob, y solo añadir archivos al índice que coincidan exactamente con las rutas especificadas en files.

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

Agrega un fetch refspec para el rmt especificado. Este refspec contendrá información sobre qué rama(s) obtener.

Ejemplos

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)

Agrega un push refspec para el rmt especificado. Este refspec contendrá información sobre qué rama(s) empujar.

Ejemplos

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)

Lee el archivo en path y lo agrega a la base de datos de objetos de repo como un blob suelto. Devuelve el GitHash del blob resultante.

Ejemplos

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)

Devuelve la Signature del autor del commit c. El autor es la persona que realizó cambios en el/los archivo(s) relevante(s). Ver también committer.

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

Devuelve todos los autores de los commits en el repositorio repo.

Ejemplos

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)

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

branch(repo::GitRepo)

Equivalente a git branch. Crea una nueva rama a partir del HEAD actual.

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

Crea una nueva rama git en el repositorio repo. commit es el GitHash, en forma de cadena, que será el inicio de la nueva rama. Si commit es una cadena vacía, se utilizará el HEAD actual.

Los argumentos clave son:

• track::AbstractString="": el nombre de la rama remota que esta nueva rama debería rastrear, si la hay. Si está vacío (el valor predeterminado), no se rastreará ninguna rama remota.
• force::Bool=false: si es true, la creación de la rama se forzará.
• set_head::Bool=true: si es true, después de que la creación de la rama finalice, la cabeza de la rama se establecerá como el HEAD de repo.

Equivalente a git checkout [-b|-B] <branch_name> [<commit>] [--track <track>].

Ejemplos

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

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

Equivalente a git checkout [-f] --detach <commit>. Realiza el checkout del commit de git commit (un GitHash en forma de cadena) en repo. Si force es true, fuerza el checkout y descarta cualquier cambio actual. Ten en cuenta que esto desacopla el HEAD actual.

Ejemplos

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
# fallaría sin el force=true
# ya que hay modificaciones en el archivo
LibGit2.checkout!(repo, string(commit_oid), force=true)

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

Clona el repositorio remoto en repo_url (que puede ser una URL remota o una ruta en el sistema de archivos local) a repo_path (que debe ser una ruta en el sistema de archivos local). Las opciones para la clonación, como si se debe realizar una clonación bare o no, se establecen mediante CloneOptions.

Ejemplos

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

Clona un repositorio remoto ubicado en repo_url a la ubicación del sistema de archivos local repo_path.

Los argumentos de palabra clave son:

• branch::AbstractString="": qué rama del remoto clonar, si no es la rama predeterminada del repositorio (generalmente master).
• isbare::Bool=false: si es true, clona el remoto como un repositorio bare, lo que hará que repo_path sea el directorio git en lugar de repo_path/.git. Esto significa que no se puede extraer un árbol de trabajo. Juega el papel del argumento de la CLI de git --bare.
• remote_cb::Ptr{Cvoid}=C_NULL: un callback que se utilizará para crear el remoto antes de que se clone. Si es C_NULL (el predeterminado), no se intentará crear el remoto; se asumirá que ya existe.
• credentials::Creds=nothing: proporciona credenciales y/o configuraciones al autenticar contra un repositorio privado.
• callbacks::Callbacks=Callbacks(): callbacks y cargas útiles proporcionadas por el usuario.

Equivalente a git clone [-b <branch>] [--bare] <repo_url> <repo_path>.

Ejemplos

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

Envoltorio alrededor de git_commit_create. Crea un commit en el repositorio repo. msg es el mensaje del commit. Devuelve el OID del nuevo commit.

Los argumentos de palabra clave son:

• refname::AbstractString=Consts.HEAD_FILE: si no es NULL, el nombre de la referencia a actualizar para apuntar al nuevo commit. Por ejemplo, "HEAD" actualizará el HEAD de la rama actual. Si la referencia aún no existe, se creará.
• author::Signature = Signature(repo) es una Signature que contiene información sobre la persona que creó el commit.
• committer::Signature = Signature(repo) es una Signature que contiene información sobre la persona que comprometió el commit en el repositorio. No necesariamente es la misma que author, por ejemplo, si author envió un parche a committer que lo comprometió.
• tree_id::GitHash = GitHash() es un árbol git que se utilizará para crear el commit, mostrando su ascendencia y relación con cualquier otra historia. tree debe pertenecer a repo.
• parent_ids::Vector{GitHash}=GitHash[] es una lista de commits por GitHash que se utilizarán como commits padre para el nuevo, y puede estar vacía. Un commit puede tener múltiples padres si es un commit de fusión, por ejemplo.

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

Confirma el parche actual al rebase rb, utilizando sig como el firmante. Es silencioso si el commit ya ha sido aplicado.

committer(c::GitCommit)

Devuelve la Signature del committer del commit c. El committer es la persona que realizó los cambios originalmente creados por el author, pero no tiene que ser el mismo que el author, por ejemplo, si el author envió un parche a un committer que lo comprometió.

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

Usando el GitRevWalker walker para "caminar" sobre cada commit en la historia del repositorio, encuentra el número de commits que devuelven true cuando se aplica f a ellos. Los argumentos clave son: * oid: El GitHash del commit desde el cual comenzar el recorrido. El valor predeterminado es usar push_head! y, por lo tanto, el commit HEAD y todos sus ancestros. * by: El método de ordenamiento. El valor predeterminado es no ordenar. Otras opciones son ordenar por topología (LibGit2.Consts.SORT_TOPOLOGICAL), ordenar hacia adelante en el tiempo (LibGit2.Consts.SORT_TIME, el más antiguo primero) o ordenar hacia atrás en el tiempo (LibGit2.Consts.SORT_REVERSE, el más reciente primero). * rev: Si se debe invertir el orden de los resultados ordenados (por ejemplo, si se utiliza el ordenamiento topológico).

Ejemplos

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 encuentra el número de commits a lo largo del recorrido con un cierto GitHash commit_oid1, comenzando el recorrido desde ese commit y avanzando en el tiempo desde él. Dado que el GitHash es único para un commit, cnt será 1.

counthunks(blame::GitBlame)

Devuelve el número de "hunks" distintos con un archivo. Un hunk puede contener múltiples líneas. Un hunk es generalmente una parte de un archivo que fue añadida/cambiada/eliminada junta, por ejemplo, una función añadida a un archivo fuente o un bucle interno que fue optimizado fuera de esa función más tarde.

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

Crea una nueva rama en el repositorio repo con el nombre bname, que apunta al commit commit_obj (que debe ser parte de repo). Si force es true, sobrescribe una rama existente llamada bname si existe. Si force es false y ya existe una rama llamada bname, esta función lanzará un error.

credential_callback(...) -> Cint

Una función de callback de credenciales de LibGit2 que proporciona diferentes funcionalidades de adquisición de credenciales con respecto a un protocolo de conexión. El payload_ptr debe contener un objeto LibGit2.CredentialPayload que mantendrá el seguimiento del estado y la configuración.

El allowed_types contiene una máscara de bits de valores LibGit2.Consts.GIT_CREDTYPE que especifican qué métodos de autenticación deben intentarse.

La autenticación de credenciales se realiza en el siguiente orden (si es compatible):

• Agente SSH
• Par de claves privadas/públicas SSH
• Nombre de usuario/contraseña en texto plano

Si se presenta a un usuario un aviso de credenciales, puede abortar el aviso escribiendo ^D (presionando la tecla de control junto con la tecla d).

Nota: Debido a las especificidades del procedimiento de autenticación de libgit2, cuando la autenticación falla, esta función se llama nuevamente sin ninguna indicación de si la autenticación fue exitosa o no. Para evitar un bucle infinito al usar repetidamente las mismas credenciales defectuosas, mantendremos un seguimiento del estado utilizando el payload.

Para más detalles, consulte la guía de LibGit2 sobre autenticación contra un servidor.

Puntero a función C para credentials_callback

Devuelve el objeto de firma. Libéralo después de usarlo.

LibGit2.delete_branch(branch::GitReference)

Elimina la rama apuntada por branch.

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

Muestra qué archivos han cambiado en el repositorio git repo entre las ramas branch1 y branch2.

El argumento de palabra clave es:

• filter::Set{Consts.DELTA_STATUS}=Set([Consts.DELTA_ADDED, Consts.DELTA_MODIFIED, Consts.DELTA_DELETED])), y establece opciones para el diff. El valor predeterminado es mostrar archivos añadidos, modificados o eliminados.

Devuelve solo los nombres de los archivos que han cambiado, no su contenido.

Ejemplos

LibGit2.branch!(repo, "branch/a")
LibGit2.branch!(repo, "branch/b")
# añade un archivo al repositorio
open(joinpath(LibGit2.path(repo),"file"),"w") do f
    write(f, "hello repo
")
end
LibGit2.add!(repo, "file")
LibGit2.commit(repo, "add file")
# devuelve ["file"]
filt = Set([LibGit2.Consts.DELTA_ADDED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)
# devuelve [] porque los archivos existentes no fueron modificados
filt = Set([LibGit2.Consts.DELTA_MODIFIED])
files = LibGit2.diff_files(repo, "branch/a", "branch/b", filter=filt)

Equivalente a git diff --name-only --diff-filter=<filter> <branch1> <branch2>.

entryid(te::GitTreeEntry)

Devuelve el GitHash del objeto al que se refiere te.

entrytype(te::GitTreeEntry)

Devuelve el tipo del objeto al que se refiere te. El resultado será uno de los tipos que devuelve objtype, por ejemplo, un GitTree o GitBlob.

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

Obtiene del repositorio remoto git rmt especificado, utilizando refspecs para determinar qué rama(s) remota(s) obtener. Los argumentos de palabra clave son:

• options: determina las opciones para la obtención, por ejemplo, si se debe podar después. Consulta FetchOptions para más información.
• msg: un mensaje para insertar en los reflogs.

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

Obtiene actualizaciones de un upstream del repositorio repo.

Los argumentos de palabra clave son:

• remote::AbstractString="origin": qué remoto, especificado por nombre, de repo se va a obtener. Si está vacío, se utilizará la URL para construir un remoto anónimo.
• remoteurl::AbstractString="": la URL de remote. Si no se especifica, se asumirá en función del nombre dado de remote.
• refspecs=AbstractString[]: determina las propiedades de la obtención.
• credentials=nothing: proporciona credenciales y/o configuraciones al autenticar contra un remote privado.
• callbacks=Callbacks(): callbacks y cargas útiles proporcionados por el usuario.

Equivalente a git fetch [<remoteurl>|<repo>] [<refspecs>].

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

Devuelve la lista de todos los fetch heads para repo, cada uno representado como un FetchHead, incluyendo sus nombres, URLs y estados de fusión.

Ejemplos

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}

Obtiene los refspecs de fetch para el rmt especificado. Estos refspecs contienen información sobre qué rama(s) obtener.

Ejemplos

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

Puntero a función C para fetchhead_foreach_callback

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

Encuentra una base de fusión (un ancestro común) entre los commits one y two. one y two pueden estar en forma de cadena. Devuelve el GitHash de la base de fusión.

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

Realiza una fusión de git en el repositorio repo, fusionando commits con historia divergente en la rama actual. Devuelve true si la fusión tuvo éxito, false si no.

Los argumentos clave son:

• committish::AbstractString="": Fusiona el/los commit(s) nombrados en committish.
• branch::AbstractString="": Fusiona la rama branch y todos sus commits desde que divergió de la rama actual.
• fastforward::Bool=false: Si fastforward es true, solo fusiona si la fusión es un avance rápido (la cabeza de la rama actual es un ancestro de los commits a fusionar), de lo contrario, se niega a fusionar y devuelve false. Esto es equivalente a la opción de CLI de git --ff-only.
• merge_opts::MergeOptions=MergeOptions(): merge_opts especifica opciones para la fusión, como la estrategia de fusión en caso de conflictos.
• checkout_opts::CheckoutOptions=CheckoutOptions(): checkout_opts especifica opciones para el paso de checkout.

Equivalente a git merge [--ff-only] [<committish> | <branch>].

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

Fusiona los cambios de los commits anotados (capturados como GitAnnotated objetos) anns en el HEAD del repositorio repo. Los argumentos de palabra clave son:

• merge_opts::MergeOptions = MergeOptions(): opciones sobre cómo realizar la fusión, incluyendo si se permite el avance rápido. Consulta MergeOptions para más información.
• checkout_opts::CheckoutOptions = CheckoutOptions(): opciones sobre cómo realizar el checkout. Consulta CheckoutOptions para más información.

anns puede referirse a cabezas de ramas remotas o locales. Devuelve true si la fusión es exitosa, de lo contrario devuelve false (por ejemplo, si no es posible la fusión porque las ramas no tienen un ancestro común).

Ejemplos

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

# fusiona la rama
LibGit2.merge!(repo, [upst_ann])

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

Fusiona los cambios de los commits anotados (capturados como GitAnnotated objetos) anns en el HEAD del repositorio repo. Si fastforward es true, solo se permite una fusión de avance rápido. En este caso, si ocurren conflictos, la fusión fallará. De lo contrario, si fastforward es false, la fusión puede producir un archivo de conflicto que el usuario deberá resolver.

Los argumentos de palabra clave son:

• merge_opts::MergeOptions = MergeOptions(): opciones sobre cómo realizar la fusión, incluyendo si se permite el avance rápido. Consulta MergeOptions para más información.
• checkout_opts::CheckoutOptions = CheckoutOptions(): opciones sobre cómo realizar el checkout. Consulta CheckoutOptions para más información.

anns puede referirse a cabezas de ramas remotas o locales. Devuelve true si la fusión es exitosa, de lo contrario devuelve false (por ejemplo, si no es posible la fusión porque las ramas no tienen un ancestro común).

Ejemplos

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

# fusionar la rama, avance rápido
LibGit2.merge!(repo, [upst_ann_1], true)

# ¡conflictos de fusión!
upst_ann_2 = LibGit2.GitAnnotated(repo, "branch/b")
# fusionar la rama, intentar avanzar rápido
LibGit2.merge!(repo, [upst_ann_2], true) # devolverá false
LibGit2.merge!(repo, [upst_ann_2], false) # devolverá true

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

Fusion de avance rápido de cambios en el HEAD actual. Esto solo es posible si el commit al que se refiere ann desciende del HEAD actual (por ejemplo, si se están extrayendo cambios de una rama remota que simplemente está por delante de la punta de la rama local).

LibGit2.fullname(ref::GitReference)

Devuelve el nombre de la referencia apuntada por la referencia simbólica ref. Si ref no es una referencia simbólica, devuelve una cadena vacía.

features()

Devuelve una lista de características de git que la versión actual de libgit2 soporta, como subprocesos o el uso de HTTPS o SSH.

filename(te::GitTreeEntry)

Devuelve el nombre del archivo del objeto en disco al que se refiere te.

filemode(te::GitTreeEntry) -> Cint

Devuelve el modo de archivo UNIX del objeto en disco al que se refiere te como un entero.

LibGit2.gitdir(repo::GitRepo)

Devuelve la ubicación de los archivos "git" de repo:

• para repositorios normales, esta es la ubicación de la carpeta .git.
• para repositorios bare, esta es la ubicación del propio repositorio.

Ver también workdir, path.

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

Crea una cadena basada en los componentes de la URL proporcionados. Cuando no se proporciona la palabra clave scheme, la URL producida utilizará la sintaxis similar a scp alternativa.

Palabras clave

• scheme::AbstractString="": el esquema de la URL que identifica el protocolo a utilizar. Para HTTP usa "http", para SSH usa "ssh", etc. Cuando no se proporciona scheme, el formato de salida será "ssh" pero utilizando la sintaxis similar a scp.
• username::AbstractString="": el nombre de usuario a utilizar en la salida si se proporciona.
• password::AbstractString="": la contraseña a utilizar en la salida si se proporciona.
• host::AbstractString="": el nombre del host a utilizar en la salida. Se requiere especificar un nombre de host.
• port::Union{AbstractString,Integer}="": el número de puerto a utilizar en la salida si se proporciona. No se puede especificar al usar la sintaxis similar a scp.
• path::AbstractString="": la ruta a utilizar en la salida si se proporciona.

Ejemplos

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

Construye un objeto de hash git a partir de la cadena dada, devolviendo un GitShortHash si la cadena es más corta que 40 dígitos hexadecimales, de lo contrario un GitHash.

Ejemplos

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

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

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

Devuelve un GitReference al HEAD actual de repo.

head(pkg::AbstractString) -> String

Devuelve el HEAD actual GitHash del repositorio pkg como una cadena.

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

Establece el HEAD de repo al objeto apuntado por ref.

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

Busca el id del objeto del HEAD actual del repositorio git repo.

LibGit2.headname(repo::GitRepo)

Busca el nombre del HEAD actual del repositorio git repo. Si repo está actualmente desacoplado, devuelve el nombre del HEAD del cual está desacoplado.

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

Abre un nuevo repositorio git en path. Si bare es false, el árbol de trabajo se creará en path/.git. Si bare es true, no se creará ningún directorio de trabajo.

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

Devuelve true si a, un GitHash en forma de cadena, es un ancestro de b, un GitHash en forma de cadena.

Ejemplos

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

Utiliza una heurística para adivinar si un archivo es binario: buscando bytes NULL y buscando una relación razonable de caracteres imprimibles a no imprimibles entre los primeros 8000 bytes.

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

Verifica si el commit id (que es un GitHash en forma de cadena) está en el repositorio.

Ejemplos

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)

Verifica si hay diferencias entre el árbol especificado por treeish y los archivos rastreados en el árbol de trabajo (si cached=false) o el índice (si cached=true). pathspecs son las especificaciones para las opciones del diff.

Ejemplos

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdiff(repo, "HEAD") # debería ser falso
open(joinpath(repo_path, new_file), "a") do f
    println(f, "aquí está mi genial nuevo archivo")
end
LibGit2.isdiff(repo, "HEAD") # ahora verdadero

Equivalente a git diff-index <treeish> [-- <pathspecs>].

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

Verifica si ha habido cambios en los archivos rastreados en el árbol de trabajo (si cached=false) o en el índice (si cached=true). pathspecs son las especificaciones para las opciones del diff.

Ejemplos

repo = LibGit2.GitRepo(repo_path)
LibGit2.isdirty(repo) # debería ser falso
open(joinpath(repo_path, new_file), "a") do f
    println(f, "aquí está mi nuevo archivo genial")
end
LibGit2.isdirty(repo) # ahora verdadero
LibGit2.isdirty(repo, new_file) # ahora verdadero

Equivalente a git diff-index HEAD [-- <pathspecs>].

LibGit2.isorphan(repo::GitRepo)

Verifica si la rama actual es una rama "huérfana", es decir, no tiene commits. El primer commit de esta rama no tendrá padres.

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

Prueba si los bits de val indexados por flag están establecidos (1) o no establecidos (0).

iszero(id::GitHash) -> Bool

Determina si todos los dígitos hexadecimales del GitHash dado son cero.

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

Determina si la rama especificada por branch_name existe en el repositorio repo. Si remote es true, se asume que repo es un repositorio git remoto. De lo contrario, es parte del sistema de archivos local.

Devuelve ya sea un GitReference a la rama solicitada si existe, o nothing si no.

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

Usando el GitRevWalker walker para "caminar" sobre cada commit en la historia del repositorio, aplica f a cada commit en el recorrido. Los argumentos clave son: * oid: El GitHash del commit desde el cual comenzar el recorrido. El valor predeterminado es usar push_head! y, por lo tanto, el commit HEAD y todos sus ancestros. * range: Un rango de GitHashs en el formato oid1..oid2. f se aplicará a todos los commits entre los dos. * by: El método de ordenamiento. El valor predeterminado es no ordenar. Otras opciones son ordenar por topología (LibGit2.Consts.SORT_TOPOLOGICAL), ordenar hacia adelante en el tiempo (LibGit2.Consts.SORT_TIME, el más antiguo primero) o ordenar hacia atrás en el tiempo (LibGit2.Consts.SORT_REVERSE, el más reciente primero). * rev: Si se debe invertir el orden ordenado (por ejemplo, si se utiliza el ordenamiento topológico).

Ejemplos

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

Aquí, LibGit2.map visita cada commit usando el GitRevWalker y encuentra su GitHash.

Función de callback de espejo

La función establece los refspecs +refs/*:refs/* y la bandera mirror para la referencia remota.

Puntero a función en C para mirror_callback

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

Devuelve el mensaje de confirmación que describe los cambios realizados en la confirmación c. Si raw es false, devuelve un mensaje ligeramente "limpiado" (que tiene cualquier salto de línea inicial eliminado). Si raw es true, el mensaje no se elimina de ningún salto de línea.

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

Ejecuta el análisis en las ramas apuntadas por las puntas de rama anotadas anns y determina bajo qué circunstancias pueden ser fusionadas. Por ejemplo, si anns[1] es simplemente un ancestro de ann[2], entonces merge_analysis informará que una fusión de avance rápido es posible.

Devuelve dos salidas, analysis y preference. analysis tiene varios valores posibles: * MERGE_ANALYSIS_NONE: no es posible fusionar los elementos de anns. * MERGE_ANALYSIS_NORMAL: una fusión regular, cuando HEAD y los commits que el usuario desea fusionar han divergido de un ancestro común. En este caso, los cambios deben resolverse y pueden ocurrir conflictos. * MERGE_ANALYSIS_UP_TO_DATE: todos los commits de entrada que el usuario desea fusionar pueden ser alcanzados desde HEAD, por lo que no es necesario realizar ninguna fusión. * MERGE_ANALYSIS_FASTFORWARD: el commit de entrada es un descendiente de HEAD y, por lo tanto, no es necesario realizar ninguna fusión; en su lugar, el usuario puede simplemente hacer checkout del commit(s) de entrada. * MERGE_ANALYSIS_UNBORN: el HEAD del repositorio se refiere a un commit que no existe. No es posible fusionar, pero puede ser posible hacer checkout de los commits de entrada. preference también tiene varios valores posibles: * MERGE_PREFERENCE_NONE: el usuario no tiene preferencia. * MERGE_PREFERENCE_NO_FASTFORWARD: no permitir ninguna fusión de avance rápido. * MERGE_PREFERENCE_FASTFORWARD_ONLY: permitir solo fusiones de avance rápido y ningún otro tipo (que puede introducir conflictos). preference puede ser controlado a través de la configuración del repositorio o de git global.

LibGit2.nombre(ref::GitReference)

Devuelve el nombre completo de ref.

name(rmt::GitRemote)

Obtiene el nombre de un repositorio remoto, por ejemplo "origin". Si el remoto es anónimo (ver GitRemoteAnon), el nombre será una cadena vacía "".

Ejemplos

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)

El nombre de tag (por ejemplo, "v0.5").

need_update(repo::GitRepo)

Equivalente a git update-index. Devuelve true si repo necesita actualización.

objtype(obj_type::Consts.OBJECT)

Devuelve el tipo correspondiente al valor del enum.

LibGit2.path(repo::GitRepo)

Devuelve la ruta base del archivo del repositorio repo.

• para repositorios normales, esto será típicamente el directorio padre del directorio ".git" (nota: esto puede ser diferente del directorio de trabajo, consulta workdir para más detalles).
• para repositorios bare, esta es la ubicación de los archivos "git".

Consulta también gitdir, workdir.

peel([T,] ref::GitReference)

Pelar recursivamente ref hasta obtener un objeto del tipo T. Si no se proporciona T, entonces ref se pelará hasta obtener un objeto que no sea un GitTag.

• Un GitTag se pelará al objeto que referencia.
• Un GitCommit se pelará a un GitTree.

peel([T,] obj::GitObject)

Pelar recursivamente obj hasta obtener un objeto del tipo T. Si no se proporciona T, entonces obj se pelará hasta que el tipo cambie.

• Un GitTag se pelará hasta el objeto que referencia.
• Un GitCommit se pelará hasta un GitTree.

LibGit2.posixpath(path)

Estandariza la cadena de ruta path para usar separadores POSIX.

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

Empuja al repositorio remoto git rmt especificado, utilizando refspecs para determinar a qué rama(s) remota(s) empujar. Los argumentos de palabra clave son:

• force: si es true, se realizará un empuje forzado, ignorando los conflictos.
• options: determina las opciones para el empuje, por ejemplo, qué encabezados de proxy usar. Consulta PushOptions para más información.

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

Envía actualizaciones a un upstream de repo.

Los argumentos de palabra clave son:

• remote::AbstractString="origin": el nombre del remoto upstream al que enviar.
• remoteurl::AbstractString="": la URL de remote.
• refspecs=AbstractString[]: determina las propiedades del push.
• force::Bool=false: determina si el push será un push forzado, sobrescribiendo la rama remota.
• credentials=nothing: proporciona credenciales y/o configuraciones al autenticar contra un remote privado.
• callbacks=Callbacks(): callbacks y cargas útiles proporcionadas por el usuario.

Equivalente a git push [<remoteurl>|<repo>] [<refspecs>].

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

Inicia el GitRevWalker walker en el commit cid. Esta función se puede usar para aplicar una función a todos los commits desde un cierto año, pasando el primer commit de ese año como cid y luego pasando el resultado w a LibGit2.map.

LibGit2.push_head!(w::GitRevWalker)

Empuja el commit HEAD y sus ancestros sobre el GitRevWalker w. Esto asegura que HEAD y todos sus commits ancestros serán encontrados durante la caminata.

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

Obtiene los push refspecs para el rmt especificado. Estos refspecs contienen información sobre qué rama(s) empujar.

Ejemplos

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}

Obtiene los bytes en bruto del GitHash como un vector de longitud 20.

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

Lee el árbol tree (o el árbol apuntado por treehash en el repositorio perteneciente a idx) en el índice idx. El contenido actual del índice será reemplazado.

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

Intenta un rebase de fusión automático de la rama actual, desde upstream si se proporciona, o de lo contrario desde la rama de seguimiento upstream. newbase es la rama a la que se va a rebasear. Por defecto, esto es upstream.

Si surgen conflictos que no se pueden resolver automáticamente, el rebase se abortará, dejando el repositorio y el árbol de trabajo en su estado original, y la función lanzará un GitError. Esto es aproximadamente equivalente a la siguiente declaración de línea de comandos:

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

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

Obtiene una lista de todos los nombres de referencia en el repositorio repo.

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

Devuelve un Cint correspondiente al tipo de ref:

• 0 si la referencia es inválida
• 1 si la referencia es un id de objeto
• 2 si la referencia es simbólica

LibGit2.remotes(repo::GitRepo)

Devuelve un vector con los nombres de los remotos de repo.

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

Elimina todos los archivos con rutas especificadas por files en el índice idx (o el índice del repo).

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

Desactiva los bits de val indexados por flag, devolviéndolos a 0.

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

Restablece el estado del payload a los valores iniciales para que pueda ser utilizado nuevamente dentro de la devolución de llamada de credenciales. Si se proporciona una config, la configuración también se actualizará.

Actualiza algunas entradas, determinadas por los pathspecs, en el índice del árbol de commits objetivo.

Establece la cabeza actual al oid de commit especificado y, opcionalmente, restablece el índice y el árbol de trabajo para que coincidan.

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

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

Restablece el repositorio repo a su estado en id, utilizando uno de los tres modos establecidos por mode:

1. Consts.RESET_SOFT - mover HEAD a id.
2. Consts.RESET_MIXED - por defecto, mover HEAD a id y restablecer el índice a id.
3. Consts.RESET_HARD - mover HEAD a id, restablecer el índice a id y descartar todos los cambios en el trabajo.

Ejemplos

# obtener cambios
LibGit2.fetch(repo)
isfile(joinpath(repo_path, our_file)) # será falso

# fusión rápida de los cambios
LibGit2.merge!(repo, fastforward=true)

# porque no había ningún archivo localmente, pero hay
# un archivo de forma remota, necesitamos restablecer la rama
head_oid = LibGit2.head_oid(repo)
new_head = LibGit2.reset!(repo, head_oid, LibGit2.Consts.RESET_HARD)

En este ejemplo, el remoto del que se está obteniendo sí tiene un archivo llamado our_file en su índice, por lo que debemos restablecer.

Equivalente a git reset [--soft | --mixed | --hard] <id>.

Ejemplos

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
# descartará los cambios en file1
# y lo desestará
new_head = LibGit2.reset!(repo, head_oid, mode)

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

Devuelve un repositorio repo a un State s anterior, por ejemplo, el HEAD de una rama antes de un intento de fusión. s se puede generar utilizando la función snapshot.

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

Lista el número de revisiones entre commit1 y commit2 (OID de commit en forma de cadena). Dado que commit1 y commit2 pueden estar en diferentes ramas, revcount realiza una lista de revisiones "izquierda-derecha" (y cuenta), devolviendo una tupla de Ints - el número de commits a la izquierda y a la derecha, respectivamente. Un commit a la izquierda (o a la derecha) se refiere a qué lado de una diferencia simétrica en un árbol se puede alcanzar el commit.

Equivalente a git rev-list --left-right --count <commit1> <commit2>.

Ejemplos

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

Esto devolverá (-1, 0).

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

Establece tanto la url de fetch como la de push para remote_name para el GitRepo o el repositorio git ubicado en path. Típicamente, los repositorios git utilizan "origin" como el nombre remoto.

Ejemplos

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)

Devuelve una versión abreviada del nombre de ref que es "legible por humanos".

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

Toma una instantánea del estado actual del repositorio repo, almacenando el HEAD actual, el índice y cualquier trabajo no confirmado. La salida State se puede usar más tarde durante una llamada a restore para devolver el repositorio al estado instantáneo.

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

Descompone el ConfigEntry en las siguientes partes: sección, subsección, nombre y valor.

Ejemplos

Dada la configuración de git que contiene:

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

El ConfigEntry se vería así:

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

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

Consulta la documentación de sintaxis de git config para más detalles.

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

Consulta el estado del archivo en path en el repositorio git repo. Por ejemplo, esto se puede usar para verificar si el archivo en path ha sido modificado y necesita ser preparado y confirmado.

stage(ie::IndexEntry) -> Cint

Obtiene el número de etapa de ie. El número de etapa 0 representa el estado actual del árbol de trabajo, pero se pueden usar otros números en caso de un conflicto de fusión. En tal caso, los diversos números de etapa en un IndexEntry describen a qué lado(s) del conflicto pertenece el estado actual del archivo. La etapa 0 es el estado antes de la fusión intentada, la etapa 1 son los cambios que se han realizado localmente, las etapas 2 y superiores son para cambios de otras ramas (por ejemplo, en el caso de una fusión "octopus" de múltiples ramas, se podrían usar las etapas 2, 3 y 4).

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

Crea una nueva etiqueta git tag (por ejemplo, "v0.5") en el repositorio repo, en el commit commit.

Los argumentos de palabra clave son:

• msg::AbstractString="": el mensaje para la etiqueta.
• force::Bool=false: si es true, las referencias existentes serán sobrescritas.
• sig::Signature=Signature(repo): la firma del etiquetador.

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

Elimina la etiqueta git tag del repositorio repo.

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

Obtiene una lista de todas las etiquetas en el repositorio git repo.

LibGit2.target(tag::GitTag)

El GitHash del objeto objetivo de tag.

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

Cambia los bits de val indexados por flag, de modo que si un bit es 0, se convertirá en 1 después del cambio, y viceversa.

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

Aplica la función f al repositorio git repo, tomando un snapshot antes de aplicar f. Si ocurre un error dentro de f, repo se devolverá a su estado de snapshot utilizando restore. El error que ocurrió será lanzado de nuevo, pero el estado de repo no se verá corrompido.

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

Recorre las entradas en tree y sus subárboles en orden post o pre. El orden pre significa comenzar en la raíz y luego recorrer el subárbol más a la izquierda (y recursivamente hacia abajo a través de los subárboles más a la izquierda de ese subárbol) y moverse a la derecha a través de los subárboles. El orden post significa comenzar en la parte inferior del subárbol más a la izquierda, recorrer hacia arriba a través de él, luego recorrer el siguiente subárbol a la derecha (nuevamente comenzando desde la parte inferior) y finalmente visitar la raíz del árbol al final.

El parámetro de función f debe tener la siguiente firma:

(String, GitTreeEntry) -> Cint

Un valor negativo devuelto de f detiene el recorrido del árbol. Un valor positivo significa que la entrada se omitirá si post es false.

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

Determina si la rama que contiene ref tiene una rama upstream especificada.

Devuelve ya sea un GitReference a la rama upstream si existe, o nothing si la rama solicitada no tiene un contraparte upstream.

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

Actualiza todos los archivos con rutas especificadas por files en el índice idx (o el índice del repo). Coincide el estado de cada archivo en el índice con el estado actual en el disco, eliminándolo si ha sido eliminado en el disco, o actualizando su entrada en la base de datos de objetos.

url(rmt::GitRemote)

Obtén la URL de obtención de un repositorio git remoto.

Ejemplos

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

Devuelve la versión de libgit2 en uso, como un VersionNumber.

with(f::Function, obj)

Función auxiliar de gestión de recursos. Aplica f a obj, asegurándose de llamar a close en obj después de que f devuelva con éxito o lance un error. Asegura que los recursos de git asignados se finalicen tan pronto como ya no sean necesarios.

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

Función auxiliar de gestión de recursos. Aplica f a args, primero construyendo una instancia del tipo T a partir de args. Asegura que se llame a close en el objeto resultante después de que f devuelva exitosamente o lance un error. Asegura que los recursos de git asignados se finalicen tan pronto como ya no sean necesarios. Si f lanza un error, se muestra una advertencia que contiene el error. ```

LibGit2.workdir(repo::GitRepo)

Devuelve la ubicación del directorio de trabajo de repo. Esto generará un error para repositorios bare.

Véase también gitdir, path.

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

Obtiene el objeto git al que se refiere te y lo devuelve como su tipo real (el tipo entrytype mostraría), por ejemplo, un GitBlob o GitTag.

Ejemplos

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

Credenciales que solo admiten los parámetros user y password

Tipo de credencial SSH

isfilled(cred::AbstractCredential) -> Bool

Verifica que una credencial esté lista para su uso en la autenticación.

Cachéa la información de credenciales para su reutilización

LibGit2.CredentialPayload

Retiene el estado entre múltiples llamadas a la función de callback de credenciales para la misma URL. Se espera que una instancia de CredentialPayload sea reset! cada vez que se utilice con una URL diferente.

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

Almacena la credencial payload para su reutilización en una futura autenticación. Solo debe ser llamado cuando la autenticación haya sido exitosa.

La palabra clave shred controla si la información sensible en el campo de credencial del payload debe ser destruida. Solo debe establecerse en false durante las pruebas.

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

Descarta la credencial payload para que no se vuelva a utilizar en futuras autenticaciones. Solo debe ser llamado cuando la autenticación no fue exitosa.

La palabra clave shred controla si la información sensible en el campo de credenciales del payload debe ser destruida. Solo debe establecerse en false durante las pruebas.

Nivel de prioridad de un archivo de configuración.

Estos niveles de prioridad corresponden a la lógica de escalación natural (de mayor a menor) al buscar entradas de configuración en git.

• CONFIG_LEVEL_DEFAULT - Abre los archivos de configuración global, XDG y del sistema si están disponibles.
• CONFIG_LEVEL_PROGRAMDATA - A nivel del sistema en Windows, para compatibilidad con git portátil.
• CONFIG_LEVEL_SYSTEM - Archivo de configuración a nivel del sistema; /etc/gitconfig en sistemas Linux.
• CONFIG_LEVEL_XDG - Archivo de configuración compatible con XDG; típicamente ~/.config/git/config.
• CONFIG_LEVEL_GLOBAL - Archivo de configuración específico del usuario (también llamado archivo de configuración global); típicamente ~/.gitconfig.
• CONFIG_LEVEL_LOCAL - Archivo de configuración específico del repositorio; $WORK_DIR/.git/config en repositorios no bare.
• CONFIG_LEVEL_APP - Archivo de configuración específico de la aplicación; definido libremente por las aplicaciones.
• CONFIG_HIGHEST_LEVEL - Representa el archivo de configuración de nivel más alto disponible (es decir, el archivo de configuración más específico disponible que realmente se carga).