Manual de usuario de Magit

Magit es una interfaz para el sistema de control de versiones Git, implementado como un paquete Emacs. Magit aspira a ser una porcelana completa de Git. Aunque no podemos afirmar (todavía) que Magit envuelva y mejore todos y cada uno de los comandos de Git, es lo suficientemente completo como para permitir incluso a los usuarios experimentados de Git realizar casi todas sus tareas diarias de control de versiones directamente desde Emacs. Aunque existen muchos buenos clientes Git, sólo Magit y el propio Git merecen ser llamados porcelanas.

Este manual es para la versión 3.3.0.50-git de Magit.

Copyright (C) 2015-2023 Jonas Bernoulli

Puede redistribuir este documento y/o modificarlo bajo los términos de la Licencia Pública General GNU publicada por la Free Software Foundation, ya sea la versión 3 de la Licencia, o (a su elección) cualquier versión posterior.

Este documento se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; ni siquiera la garantía implícita de COMERCIABILIDAD o IDONEIDAD PARA UN PROPÓSITO PARTICULAR. Para más detalles, consulte la Licencia Pública General GNU.

Introducción

Magit es una interfaz para el sistema de control de versiones Git, implementada como un paquete de Emacs. Magit aspira a ser una porcelana completa de Git. Aunque no podemos afirmar (todavía) que Magit envuelva y mejore todos y cada uno de los comandos de Git, es lo suficientemente completo como para permitir incluso a los usuarios experimentados de Git llevar a cabo casi todas sus tareas diarias de control de versiones directamente desde Emacs. Aunque existen muchos buenos clientes Git, sólo Magit y el propio Git merecen ser llamados porcelanas.

El staging (área de preparación) y la aplicación de cambios es una de las características más importantes en una porcelana Git y aquí Magit eclipsa a cualquier otra cosa, incluyendo al propio Git. La propia interfaz de puesta en escena de Git (git add --patch) es tan engorrosa que muchos usuarios sólo la usan en casos excepcionales. En Magit, poner en staging un hunk o incluso sólo parte de un hunk¹ es tan trivial como poner en en el área de preparación (staging) todos los cambios realizados en un archivo.

La parte más visible de la interfaz de Magit es el buffer de estado, que muestra información sobre el repositorio actual. Su contenido se crea ejecutando varios comandos Git y haciendo que su salida sea procesable. Entre otras cosas, muestra información sobre la rama actual, enumera los cambios no extraídos ni empujados (unpulled y unpushed) y contiene secciones que muestran los cambios incorporados o no al área de preparación. Puede sonar ruidoso, pero como las secciones son plegables, no lo es.

El cambio puede ser un fichero, una parte de él, o cuando la región está activa (es decir, cuando hay una selección) varios ficheros o partes de ficheros, o incluso sólo parte de un trozo. El cambio o cambios sobre los que actuarían estos comandos -y muchos otros- aparecen resaltados.

Magit también implementa otras "variantes de aplicación" además de incluir o no en el area de preparación. Uno puede descartar o revertir un cambio, o aplicarlo al árbol de trabajo. La propia porcelana de Git sólo soporta esto para la puesta en escena y la desagrupación, y tendría que hacer algo como git diff ... | ??? | git apply ... para descartar, revertir o aplicar una única parte en la línea de comandos. De hecho, eso es exactamente lo que Magit hace internamente (que es lo que llevó al término "aplicar variantes").

Magit no es sólo para expertos en Git, pero asume cierta experiencia previa con Git así como con Emacs. Dicho esto, muchos usuarios han informado de que usar Magit fue lo que finalmente les enseñó de lo que Git es capaz y cómo usarlo al máximo. Otros usuarios desearían haberse pasado antes a Emacs para haber tenido antes a Magit en sus manos.

Aunque hay que conocer las características básicas de Emacs para poder utilizar Magit plenamente, adquirir los conocimientos suficientes sobre el Editor no lleva mucho tiempo y merece la pena, incluso para los usuarios que prefieren otros editores. Se recomienda a los usuarios de Vim que prueben Evil, la "Extensible VI Layer for Emacs", y Spacemacs, un "Conjunto de Herramientas para iniciar Emacs (starter-kit) centrado en Evil".

Magit proporciona una porcelana Git consistente y eficiente. Tras un breve periodo de aprendizaje, será capaz de hacer la mayor parte de sus tareas diarias de control de versiones más rápido de lo que lo haría en la línea de comandos. También es probable que empiece a usar funciones que antes le parecían demasiado desalentadoras.

Magit adopta plenamente Git. Expone muchas características avanzadas usando una interfaz simple pero flexible en lugar de envolver sólo las triviales como hacen muchos clientes GUI. Por supuesto, Magit soporta inicio de sesion (logging), clonación (clone), envío (push) y otros comandos que normalmente no fallan de forma espectacular; pero también soporta tareas que a menudo no pueden completarse en un solo paso. Magit soporta completamente tareas como fusionar (merge), rebasar (rebase), entresacar (llevar trabajo de una rama a otra, cherry-picking), revertir y blaming² no sólo proporcionando un comando para iniciar estas tareas sino también mostrando información sensible al contexto a lo largo del camino y proporcionando comandos que son útiles para resolver conflictos y reanudar la secuencia después de hacerlo.

Magit es la interface y en muchos casos mejora al menos los siguientes comandos de porcelana Git: add, am, bisect, blame, branch, checkout, cherry, cherry-pick, clean, clone, commit, config, describe, diff, fetch, format-patch, init, log, merge, merge-tree, mv, notes, pull, rebase, reflog, remote, request-pull, , , rm, show, stash, submodule, subtree, tag y . Muchos más comandos de porcelana Magit se implementan sobre comandos de fontanería Git.

Instalación

Magit puede instalarse mediante el gestor de paquetes de Emacs o manualmente desde su repositorio de desarrollo.

Instalación desde Melpa

Magit está disponible desde Melpa y Melpa-Stable. Si no ha usado antes el gestor de paquetes de Emacs, es hora de que se familiarice con él leyendo la documentación en el manual de Emacs, vea (emacs)Packages. Después añade uno de los archivos a package-archives:

• Para usar Melpa

  (require 'package)
  (add-to-list 'package-archives
               '("melpa" . "https://melpa.org/packages/") t)
  	

• Para usar Melpa-Estable:

  (require 'package)
  (add-to-list 'package-archives
               '("melpa-stable" . "https://stable.melpa.org/packages/") t)
  	

Una vez que haya añadido el archivo que prefiera, debe actualizar la lista de paquetes local con el comando:

M-x package-refresh-contents RET

Una vez hecho esto, puede instalar Magit y sus dependencias usando:

M-x package-install RET magit RET

Instalando desde repositorio Git

Magit depende de las bibliotecas compat, dash, transient y with-editor que están disponibles en Melpa y Melpa-Stable. Instálelas usando Alt-x package-install RET <paquete> RET (M-x package-install RET <paquete> RET). Por supuesto, también puede instalarlas manualmente desde su repositorio.

Clone el repositorio Magit:

$ git clone https://github.com/magit/magit.git ~/.config/emacs/lisp/magit
$ cd ~/.config/emacs/lisp/magit

A continuación, compile las bibliotecas y genere los manuales informativos:

$ make

Si no ha instalado compat, dash, transient y with-editor desde Melpa o en /ruta/a/magit/../<paquete>, entonces tiene que decirle a make donde encontrarlos. Para ello cree el archivo /ruta/a/magit/config.mk con el siguiente contenido antes de ejecutar make:

LOAD_PATH  = -L ~/.config/emacs/lisp/magit/lisp
LOAD_PATH += -L ~/.config/emacs/lisp/dash
LOAD_PATH += -L ~/.config/emacs/lisp/transient/lisp
LOAD_PATH += -L ~/.config/emacs/lisp/with-editor/lisp
LOAD_PATH += -L ~/.config/emacs/lisp/compat

Finalmente escriba lo siguiente en el archivo init:

(add-to-list 'load-path "~/.config/emacs/lisp/magit/lisp")
(require 'magit)

(with-eval-after-load 'info
  (info-initialize)
  (add-to-list 'Info-directory-list
               "~/.config/emacs/lisp/magit/Documentación/"))

Por supuesto, si instaló las dependencias manualmente, tiene que decírselo a Emacs también, anteponiendo a lo anterior:

(add-to-list 'load-path "~/.config/emacs/lisp/dash")
(add-to-list 'load-path "~/.config/emacs/lisp/transient/lisp")
(add-to-list 'load-path "~/.config/emacs/lisp/with-editor")

Tenga en cuenta que tiene que añadir el subdirectorio lisp a la ruta de carga (load-path), no al nivel superior del repositorio, y que los elementos de la ruta de carga no deben terminar con una barra, mientras que los de Info-directory-list sí.

En lugar de requerir la característica magit, podría cargar sólo las definiciones de autoload, cargando el archivo magit-autoloads.el.

(load "/ruta/a/magit/lisp/magit-autoloads")

En lugar de ejecutar Magit directamente desde el repositorio añadiéndolo a la ruta de carga (load-path), es posible que desee instalarlo en algún otro directorio usando sudo make install y estableciendo la ruta de carga en consecuencia.

Para actualizar magit use:

$ git pull
$ make

A veces puede ser necesario ejecutar make clean all en su lugar.

Para ver todas las opciones disponibles use make help.

Tareas Posteriores a la Instalación

Después de instalar Magit debería verificar que realmente está usando las versiones de Magit, Git y Emacs que cree estar usando. Es mejor reiniciar Emacs antes de hacerlo, para asegurarse de que no está usando un valor obsoleto para load-path.

M-x magit-version RET

debería mostrar algo parecido a:

Magit 2.8.0, Git 2.10.2, Emacs 25.1.1, gnu/linux

Luego, quizá quiera leer sobre las opciones que probablemente muchos usuarios quieran personalizar. Ver Configuración esencial.

Para poder seguir las referencias cruzadas a las páginas de manual de Git que se encuentran en este manual, puede que también tenga que instalar manualmente la guía de información de gitman, o las recomendaciones de Info-follow-nearest-node para abrir la página de manual real. Consulte Cómo instalar el manual de información de gitman.

Si Ud. es completamente nuevo en Magit, consulta Cómo empezar.

Si tiene problemas, consulte las FAQ. Mire también Herramientas de depuración.

Y por último pero no menos importante, por favor considere hacer una donación, para asegurar que puedo seguir trabajando en Magit. Consulte https://magit.vc/donations. para ver varias opciones de donación.

Comenzando

Este breve tutorial describe las funciones más esenciales que muchos Magicianos usan a diario. Sólo araña la superficie, pero debería ser suficiente para empezar.

IMPORTANTE: Lo más seguro es que clone algún repositorio sólo para este tutorial. Alternativamente, puede usar un repositorio local existente, pero si lo hace, debe confirmar todos los cambios no comprometidos antes de continuar.

Primeros Pasos

Escriba Ctrl-x g (C-x g) para mostrar información sobre el repositorio Git actual en un buffer dedicado, llamado buffer de estado.

La mayoría de los comandos de Magit, habitualmente se invocan desde el buffer de estado. Puede considerarse la interfaz principal para interactuar con Git usando Magit. Pueden existir muchos otros buffers Magit en un momento dado, pero a menudo se crean a partir de este buffer.

Dependiendo del estado en el que se encuentre su repositorio, este buffer puede contener secciones tituladas "Staged changes" (Cambios preparados), "Unstaged changes" (Cambios sin preparar), "Unmerged into origin/master" (Sin confirmar dentro de origin/master), "Unpushed to origin/master" (Sin empujar a origin/master), y muchas otras.

Dado que estamos empezando desde un estado seguro, al que puede volver fácilmente (haciendo un git reset --hard PRE-MAGIT-STATE), actualmente no hay cambios escalonados o no escalonados. Edite algunos archivos y guarde los cambios. Luego vuelva al buffer de estado, al mismo tiempo que lo refresca, tecleando Ctrl-x g (C-x g). (Cuando el buffer de estado, o cualquier buffer Magit para el caso, es el buffer actual, puede usar solo g (g) para refrescarlo).

Muévase entre secciones utilizando p y n. Tenga en cuenta que los cuerpos de algunas secciones están ocultos. Escriba TAB para expandir o contraer la sección en cuestión. También puede usar Ctrl-TAB (C-tab) para cambiar la visibilidad de la sección actual y de sus secciones secundarias. Desplácese a la sección de un archivo dentro de la sección "Unstaged changes" (Cambios no preparados) y escriba s para organizar los cambios que ha realizado en ese archivo. El archivo aparecerá ahora en la sección "Staged changes" (Cambios preparados).

Magit puede subir y descargar cambios parciales, no sólo archivos completos. Muévase al archivo que acaba de preparar, expándalo usando TAB, muévase a uno de los "hunks" (a una de las partes) usando n, y saque solo esa sección del área de preparación tecleando u. Observe cómo los comandos que incluyen o excluyen archivos o partes de él en el área de preparación (s y u) llevan a cabo el cambio en el punto. Muchos otros comandos se comportan de la misma manera.

También puede preparar o sacar del área de preparación sólo una parte de un trozo (la parte de un "hunk"). Dentro del cuerpo de una sección del trozo (muévase allí usando Ctrl-n (C-n)), fije la marca usando Ctrl-SPCE (C-SPC) y muévase hacia abajo hasta que algunas líneas añadidas y/o eliminadas caigan dentro de la región pero no todas. De nuevo teclee s para añadir al área de preparación.

También es posible sacar del área de preparación varios archivos a la vez. Muévase a la sección de un fichero, teclee Ctrl-SPC (C-SPC), muévase al siguiente fichero usando n, y luego s para incluír ambos ficheros. Tenga en cuenta que tanto la marca como el punto tienen que estar en las cabeceras de las secciones hermanas para que esto funcione. Si la región tiene el mismo aspecto que en otros buffers, no selecciona secciones Magit sobre las que se pueda actuar como una unidad.

Luego, quiere confirmar sus cambios, por supuesto. Escriba c. Esto muestra los comandos y argumentos de confirmación disponibles en un búfer en la parte inferior del marco. Cada comando y argumento tiene como prefijo la tecla que lo invoca/establece. Por ahora no se preocupe por esto. Queremos crear un commit "normal" (una confirmación estandar), lo que se hace tecleando c de nuevo.

Ahora aparecen dos nuevos buffers. Uno es para escribir el mensaje de confirmación, el otro muestra un diff con los cambios que está a punto de confirmar. Escribe un mensaje y luego teclee Ctrl-c Ctrl-c (C-c C-c) para crear la confirmación (commit).

Probablemente no quiera hacer push del commit (enviar la confirmación) que acaba de crear porque acaba de confirmar algunos cambios al azar, pero si ese no es el caso podría hacer push tecleando P para mostrar todos los comandos y argumentos push disponibles y luego p para hacer push a una rama con el mismo nombre que la rama local en la remota configurada como push-remote. (Si push-remote no está configurado todavía, entonces primero se le pedirá el remoto al que hacer el push).

Hasta ahora hemos mencionado los comandos de menú commit (confirmación) y push (empujar o enviar). Estos son probablemente los menús que más utilizará, pero existen muchos otros. Para mostrar un menú que enumere todos los demás menús (así como los diversos comandos apply y algunos otros comandos esenciales), escriba h. Pruebe algunos. Estos menús también se denominan "comandos prefijo transitorios" (transient prefix commands) o simplemente "transitorios" (transients).

Las combinaciones de teclas de ese menú se corresponden con las combinaciones de las memorias intermedias de Magit, incluida, entre otras, la memoria intermedia de estado. Así que puede teclear hd (h d) para abrir el menú diff, pero una vez que recuerde que "d" significa "diff", normalmente lo hara simplemente tecleando d.

Este "prefijo de prefijos" es útil incluso una vez que ha memorizado todos los enlaces, ya que puede proporcionar un fácil acceso a los comandos Magit desde buffers que no son Magit. Así que, por defecto, está globalmente ligado a Ctrl-x Alt-g (C-x M-g).

Un menú similar que presenta (en su mayor parte) comandos que actúan sólo sobre el archivo que se está visitando en el búfer actual, globalmente está vinculado a Ctrl-c Alt-g (C-c M-g). Esta combinación también puede usarse en buffers que no visitan un archivo, pero entonces sólo está disponible un subconjunto de comandos.

Las combinaciones de teclas globales mencionadas en los dos párrafos anteriores son bastante inconvenientes. Recomendamos usar Ctrl-c g (C-c g) y Ctrl-c f (C-c f) en su lugar, pero no se pueden usar esas secuencias de teclas por defecto porque están estrictamente reservadas para vinculaciones añadidas por el usuario. Consulte Global Bindings, si quiere optar explícitamente por las combinaciones de teclas recomendadas.

Magit también proporciona menús contextuales y otros comandos de ratón, vea Soporte de ratón.

No es necesario que lo haga ahora, pero si sigue con Magit, entonces es muy recomendable que también lea la siguiente sección.

Modos y Búferes

Magit ofrece varios modos principales. Para cada uno de estos modos, normalmente sólo existe un buffer por repositorio. Existen modos separados y por tanto buffers para commits, diffs, logs y algunas otras cosas.

Además de estos buffers especiales, también existe un buffer general, llamado buffer de estado. Normalmente es desde este búfer desde donde el usuario invoca comandos Git, o crea o visita otros búferes.

En este manual hablamos a menudo de "buffers Magit". Con esto nos referimos a buffers cuyos modos mayores (major-modes) derivan de magit-mode.

Búferes de Conmutación

Nombrar Búferes

Opción de usuario: magit-generate-buffer-name-function

La función usada para generar los nombres de los buffers Magit.

Esta función debería tener en cuenta las opciones magit-uniquify-buffer-names y magit-buffer-name-format. Si no lo hace, debería indicarse claramente en el doc-string. Y si soporta %-secuencias más allá de las mencionadas en el doc-string de la opción magit-buffer-name-format, entonces su propio doc-string debería describir las adiciones.

Función: magit-generate-buffer-name-default-function-modo

Esta función devuelve un nombre de búfer adecuado para un búfer cuyo major-mode (modo-mayor) es MODE y que muestra información sobre el repositorio en el que se encuentra default-directory.

Esta función usa magit-buffer-name-format y soporta todas las secuencias % mencionadas en la documentación de dicha opción. También respeta la opción magit-uniquify-buffer-names.

Opción de usuario: magit-buffer-name-format

La cadena de formato usada para nombrar los buffers Magit.

Se admiten al menos las siguientes secuencias %:

• %m
  El nombre del modo-mayor, pero sin el sufijo -mode.
• %M
  Como %m pero abreviando magit-status-mode como magit.
• %v
  El valor al que está bloqueado el búfer, entre paréntesis, o una cadena vacía si el búfer no está bloqueado a ningún valor.
• $V
  Como %v, pero la cadena va precedida de un espacio, a menos que sea una cadena vacía.
• %t
  El directorio de nivel superior del árbol de trabajo del repositorio, o si magit-uniquify-buffer-names es distinto de nil, una abreviatura del mismo.
• %x
  Si magit-uniquify-buffer-names es nulo (nil) "*", en caso contrario la cadena vacía. Debido a las limitaciones del paquete uniquify, los nombres de los búferes deben terminar con la ruta.

El valor siempre debe contener %m o %M, %v o %V, y %t. Si magit-uniquify-buffer-names es distinto de nil, el valor debe terminar con %t o %t%x. Véase el problema nº 2841 (issue #2841).

Opción de usuario: magit-uniquify-buffer-names

Esta opción controla si los nombres de los buffers Magit están unificados. Si los nombres no se unifican, contienen la ruta completa del nivel superior del árbol de trabajo del repositorio correspondiente. Si están siendo unificados, entonces terminan con el nombre base del nivel superior, o si eso entra en conflicto con el nombre utilizado para otros buffers, entonces los nombres de todos estos buffers se ajustan hasta que ya no entren en conflicto.

Esto se hace usando el paquete uniquify; personalice sus opciones para controlar cómo se unifican los nombres de los buffers.

Cerrar Ventanas

q (q, magit-mode-bury-buffer)

Este comando entierra o mata el búfer Magit actual. La función especificada por la opción magit-bury-buffer-function se usa para enterrar el búfer cuando se invoca sin un argumento de prefijo o para matarlo cuando se invoca con un único argumento de prefijo.

Cuando se invoca con dos o más argumentos de prefijo, siempre elimina todos los búferes Magit asociados con el proyecto actual, incluido el búfer actual.

Opción de usuario: magit-bury-buffer-function

La función usada para enterrar o matar el buffer actual.

magit-mode-bury-buffer llama a esta función con un argumento. Si el argumento no es nulo, entonces la función tiene que matar el buffer actual. Si no, tiene que enterrarlo vivo. El valor por defecto es magit-mode-quit-window.

Función: magit-restore-window-configuration kill-buffer

Entierra o mata el buffer actual usando quit-window, que es llamado con KILL-BUFFER como primer argumento y la ventana seleccionada como segundo argumento.

Entonces restaura la configuración de ventana que existía justo antes de que el buffer actual se mostrara en el marco seleccionado. Desafortunadamente eso también significa que el punto se ajusta en todos los buffers, que están siendo mostrados en el marco seleccionado.

Función: magit-mode-quit-window kill-buffer

Entierra o mata el búfer actual usando quit-window, que se llama con KILL-BUFFER como primer argumento y la ventana seleccionada como segundo argumento.

Entonces, si la ventana se creó originalmente para mostrar un búfer Magit y el búfer enterrado era el último búfer Magit restante que se mostraba en la ventana, éste se elimina.

Actualización Automática de las Memorias Intermedias Magit

Después de ejecutar un comando que puede cambiar el estado del repositorio actual, el búfer Magit actual y el búfer de estado correspondiente se refrescan. El búfer de estado se puede refrescar automáticamente cada vez que se guarda un búfer en un archivo dentro del repositorio respectivo añadiendo un gancho (hook), como el siguiente:

(with-eval-after-load 'magit-mode
  (add-hook 'after-save-hook 'magit-after-save-refresh-status t))

La actualización automática de los búferes Magit garantiza que la información mostrada esté actualizada la mayor parte del tiempo, pero puede provocar un retraso considerable en repositorios grandes. Otros buffers Magit no se refrescan para mantener el retraso al mínimo y también porque hacerlo a veces puede ser indeseable.

Los buffers también se pueden actualizar explícitamente, lo que es útil en buffers que no estaban actualizados durante la última actualización y después de que se hayan hecho cambios en el repositorio fuera de Magit.

g (g, magit-refresh)

Esta orden actualiza el búfer actual si su modo principal deriva de magit-mode, así como el búfer de estado correspondiente.

Si la opción magit-revert-buffers lo requiere, entonces también revierte todos los buffers no modificados que visitan archivos que están siendo rastreados en el repositorio actual.

G (G, magit-refresh-all)

Este comando refresca todos los buffers Magit pertenecientes al repositorio actual y también revierte todos los buffers no modificados que visitan archivos que están siendo rastreados en el repositorio actual.

Los buffers que visitan archivos siempre se revierten, incluso si magit-revert-buffers es nulo (nil).

Opción de usuario: magit-refresh-buffer-hook

Este gancho se ejecuta en cada búfer Magit que haya sido refrescado durante el refresco actual - normalmente el búfer actual y el búfer de estado.

Opción de usuario: magit-refresh-status-buffer

Cuando esta opción es distinta de nil, el búfer de estado se actualiza automáticamente después de ejecutar git para side-effects, además del búfer Magit actual, que siempre se actualiza automáticamente.

Establece esta opción a nil sólo después de agotar todas las demás opciones para mejorar el rendimiento.

Función: magit-after-save-refresh-status

Esta función está pensada para ser añadida a after-save-hook. Después de hacerlo, el búfer de estado correspondiente se refresca cada vez que se guarda un búfer en un archivo dentro de un repositorio.

Tenga en cuenta que refrescar un buffer Magit se hace recreando su contenido desde cero, lo que puede ser lento en repositorios grandes. Si no está satisfecho con el rendimiento de Magit, entonces obviamente no debería añadir esta función a ese gancho (hook).

Almacenamiento Automático de las Memorias Intermedias que Visitan Archivos

Los buffers que visitan archivos se guardan por defecto en determinados momentos. Esto no garantiza que los buffers de Magit estén siempre actualizados, pero, siempre que uno sólo edite archivos con Emacs y use sólo Magit para interactuar con Git, puede estar bastante seguro. En caso de duda o después de cambios externos, teclee g (magit-refresh) para guardar y refrescar explícitamente.

Opción de Usuario: magit-save-repository-buffers

Esta opción controla si los buffers que visitan archivos se guardan antes de ciertos eventos.

Si no es nula, todos los búferes que visitan archivos modificados pertenecientes al repositorio actual pueden guardarse antes de ejecutar comandos, antes de crear nuevos búferes Magit y antes de actualizar explícitamente dichos búferes. Si es dontask, esto se hace sin intervención del usuario. Si es t entonces el usuario tiene que confirmar cada guardado.

Reversión Automática de las Búferes que Visitan Archivos

Por ejemplo, si descarta un cambio en el buffer de estado, eso se hace ejecutando git apply --reverse ..., y Emacs considera que el archivo ha "cambiado en disco". Si Magit no revirtiera automáticamente el buffer, entonces tendría que teclear (M-x revert-buffer RET RET) en el buffer de visita antes de poder seguir haciendo cambios.

Opción de Usuario: magit-auto-revert-mode

Cuando se activa este modo, los búferes que visitan archivos rastreados se revierten automáticamente después de que los archivos visitados cambien en el disco.

Opción de Usuario: global-auto-revert-mode

Cuando este modo está activado, cualquier búfer que visite un archivo se revierte automáticamente después de que el archivo visitado cambie en el disco.

Si quiere que los búferes que visitan archivos rastreados se reviertan automáticamente, es posible que también quiera que se revierta cualquier búfer, no sólo los que visitan archivos rastreados. En ese caso, active este modo en lugar de magit-auto-revert-mode.

Opción de Usuario: magit-auto-revert-immediately

Esta opción controla si Magit revierte los buffers inmediatamente.

Si no es nula y está activado el modo global-auto-revert o magit-auto-revert, Magit revertirá inmediatamente los buffers llamando explícitamente a auto-revert-buffers después dei ejecutar Git para los efectos secundarios.

Si auto-revert-use-notify es no nulo (no nil, y las notificaciones de archivos están realmente soportadas), entonces magit-auto-revert-immediately no tiene que ser non nil, porque las reversiones ocurren inmediatamente de todos modos.

Si magit-auto-revert-immediately y auto-revert-use-notify son ambos nulos, las reversiones ocurrirán después de un intervalo de auto-reversión de segundos de inactividad del usuario. Esto no es deseable.

Opción de Usuario: auto-revert-use-notify

Esta opción controla si se deben usar las funciones de notificación de archivos. Tenga en cuenta que, lamentablemente, esta variable tiene por defecto el valor t, incluso en sistemas en los que no se pueden utilizar las notificaciones de archivos.

Opción de Usuario: magit-auto-revert-tracked-only

Esta opción controla si magit-auto-revert-mode sólo revierte archivos rastreados o todos los archivos que se encuentran dentro de repositorios Git, incluyendo archivos no rastreados y archivos ubicados dentro del directorio de control de Git.

Opción de Usuario: auto-revert-mode

El modo global magit-auto-revert-mode funciona activando este modo local en los buffers apropiados (pero global-auto-revert-mode se implementa de forma diferente). También puede activarlo o desactivarlo manualmente, lo que puede ser necesario si Magit no se da cuenta de que un archivo no rastreado previamente ahora está siendo rastreado o viceversa.

Opción de Usuario: auto-revert-stop-on-user-input

Esta opción controla si la llegada de una entrada de usuario suspende las reversiones automáticas durante auto-revert-interval segundos.

Opción de Usuario: auto-revert-interval

Esta opción controla cuántos segundos espera Emacs antes de reanudar las reversiones suspendidas.

Opción de Usuario: auto-revert-buffer-list-filter

Esta opción especifica un filtro adicional utilizado por auto-revert-buffers para determinar si un buffer debe ser revertido o no.

Esta opción la proporciona Magit, que también aconseja a auto-revert-buffers que la respete. Los usuarios de Magit que no activen el modo local auto-revert-mode por sí mismos, están mejor servidos estableciendo el valor a magit-auto-revert-repository-buffer-p.

Sin embargo, el valor por defecto es nil, para no molestar a los Usuarios que sí utilizan el modo local directamente. Si experimenta retrasos al ejecutar comandos Magit, debería considerar el uso de uno de los predicados proporcionados por Magit, especialmente si también utiliza Tramp.

Los usuarios que activan el modo auto-revert en buffers en los que Magit no lo hace por ellos, probablemente no deberían usar ningún filtro. Los usuarios que activen el modo global-auto-revert, no tienen que preocuparse por esta opción, porque no se tiene en cuenta si el modo global está activado.

Opción de Uusario: auto-revert-verbose

Esta opción controla si Emacs informa cuando un buffer ha sido revertido.

Las opciones con el prefijo auto-revert- se encuentran en el grupo Custom llamado auto-revert. Las otras opciones, específicas de Magit, se encuentran en el grupo magit.

Riesgo de Reversión Automática

Para la gran mayoría de los usuarios, revertir automáticamente los buffers que visitan ficheros después de que hayan cambiado en el disco es inofensivo.

Si un buffer está modificado (es decir, contiene cambios que aún no han sido guardados), entonces Emacs se negará a revertirlo automáticamente. Si guarda un buffer previamente modificado, entonces eso resulta en lo que Git ve como un cambio no comprometido. Git se negará a ejecutar cualquier comando que pueda causar que estos cambios se pierdan. En otras palabras, si hay algo que pueda perderse, Git o Emacs se negarán a descartar los cambios.

Sin embargo, si usa buffers de visita de archivos como una especie de "área de preparación" (staging area) ad hoc, entonces las reversiones automáticas podrían potencialmente causar pérdidas de datos. Hasta ahora sólo he oído hablar de un usuario que utilice este tipo de flujo de trabajo.

Un ejemplo: Visita algún fichero en un buffer, lo edita y guarda los cambios. Entonces, fuera de Emacs (o al menos no usando Magit o guardando el buffer) cambia el fichero en disco otra vez. En este punto, el buffer es el único lugar donde la versión intermedia todavía existe. Ha guardado los cambios en el disco, pero desde entonces se han sobrescrito. Mientras tanto Emacs considera que el buffer no ha sido modificado (porque no ha hecho ningún cambio en él desde la última vez que lo guardó en el fichero visitado) y por lo tanto no se opondría a que fuera revertido automáticamente. En este punto, se activaría el modo Auto-Revertir. Comprobaría si el búfer está modificado y, como no es el caso, lo revertiría. La versión intermedia se perdería. (En realidad aún podría recuperarla usando el comando deshacer).

Si su flujo de trabajo depende de que Emacs preserve la versión intermedia en el buffer, entonces tiene que desactivar todos los modos de Auto-Revertir. Pero por favor considere que tal flujo de trabajo sería peligroso incluso sin usar un modo Auto-Revertir, y por lo tanto debería ser evitado. Si Emacs se bloquea o si sales de Emacs por error, también perderías el contenido del buffer. No habría ningún archivo de autoguardado que todavía contuviera la versión intermedia (porque se borró cuando guardó el buffer) y no se le preguntaría si quiere guardar el buffer (porque no se modifica).

Secciones

Los buffers Magit están organizados en secciones anidadas, que pueden ser colapsadas y expandidas, similar a como las secciones son manejadas en Org mode. Cada sección también tiene un tipo, y algunas secciones también tienen un valor. Para cada tipo de sección también puede haber un mapa de teclado local, compartido por todas las secciones de ese tipo.

Aprovechando el valor y el tipo de sección, muchos comandos operan en la sección actual, o cuando la región está activa y selecciona secciones del mismo tipo, en todas las secciones seleccionadas. Los comandos que sólo tienen sentido para un determinado tipo de sección (en lugar de comportarse de forma diferente según el tipo) suelen estar vinculados a mapas de teclado de tipo de sección.

Desplazamiento por Secciones

Para desplazarse dentro de una sección, use las teclas habituales (Ctrl-p (C-p), Ctrl-n (C-n), Ctrl-b (C-b), Ctrl-f (C-f), etc.), cuyos enlaces globales no están sombreados. Para desplazarse a otra sección, use los siguientes comandos.

p (p, magit-section-backward)

Cuando no está al principio de una sección, se desplaza al principio de la sección actual. Al principio de una sección, se desplaza al principio de la sección visible anterior.

n (n, magit-section-forward)

Pasa al principio de la siguiente sección visible.

Alt-p (M-p, magit-section-backward-sibling)

Se desplaza al principio de la sección de hermana anterior. Si no hay sección anterior, se desplaza a la sección principal.

Alt-n (M-n, magit-section-forward-sibling)

Se desplaza al principio de la siguiente sección hermana. Si no hay una sección hermana siguiente, se desplaza a la sección principal.

^ (^, magit-section-up)

Se desplaza al principio del padre de la sección actual.

Todos los comandos anteriores llaman al gancho magit-section-movement-hook. Cualquiera de las funciones listadas a continuación pueden ser usadas como miembros de este gancho (hook).

Puede que quiera eliminar algunas de las funciones que Magit añade usando add-hook. Al hacerlo tiene que asegurarse de que no intenta eliminar funciones que ni siquiera han sido añadidas todavía, por ejemplo:

(with-eval-after-load 'magit-diff
  (remove-hook 'magit-section-movement-hook
               'magit-hunk-set-window-start))

Variable: magit-section-movement-hook

Este gancho es ejecutado por todos los comandos de movimiento anteriores, después de llegar al destino.

Función: magit-hunk-set-window-start

Este gancho es una función y asegura que el comienzo de la sección actual es visible, siempre que sea una sección hunk. En caso contrario, no hace nada.

Carga magit-diff, añade esta función al gancho.

Función: magit-section-set-window-start

La función de este gancho asegura que el comienzo de la sección actual sea visible, independientemente del tipo de sección. Si añade esto a magit-section-movement-hook, deberá eliminar a su vez la variante hunk-only.

Función: magit-log-maybe-show-more-commits

La función de este gancho sólo tiene efecto en las memorias intermedias de registro, y el punto (point) está en la sección "mostrar más". Si ese es el caso, entonces duplica el número de commits que se muestran.

Carga magit-log y añade esta función al gancho.

Función: magit-log-maybe-update-revision-buffer

Cuando se mueve dentro de un búfer de registro, esta función actualiza el búfer de revisión, siempre que ya se esté visualizando en otra ventana del mismo marco.

Carga magit-log y añade esta función al gancho.

Función: magit-log-maybe-update-blob-buffer

Cuando se desplaza dentro de un búfer de registro y otra ventana del mismo marco muestra un búfer de blob (un bufer que puede contener binario), esta función muestra en su lugar el búfer de blob para la confirmación en el punto de esa ventana.

Función: magit-status-maybe-update-revision-buffer

Cuando se desplaza dentro de un búfer de estado, esta función actualiza el búfer de revisión, siempre que ya se esté visualizando en otra ventana del mismo marco.

Función: magit-status-maybe-update-stash-buffer

Cuando se desplaza dentro de un búfer de estado, esta función actualiza el búfer de stash ¹, siempre que ya se esté visualizando en otra ventana del mismo marco.

Importante

¹ El stashing permite mantener los cambios que se han hecho y a la vez deshacerce del archivo temporalmente, es una opción que permite esconder archivos. Este concepto escrito con otras palabras: el comando git --stash permite guardar los archivos del directorio de trabajo modificados y lo guarda en un espacio de cambios sin terminar que se puede usar en cualquier momento.

Función: magit-status-maybe-update-blob-buffer

Cuando se desplaza dentro de un búfer de estado y otra ventana del mismo marco muestra un búfer de blob, esta función muestra en su lugar el búfer de blob para la confirmación en el punto de esa ventana.

Función: magit-stashes-maybe-update-stash-buffer

Cuando se mueve dentro de un buffer que lista stashes, entonces esta función actualiza el buffer stash, siempre y cuando ya se esté mostrando en otra ventana del mismo marco.

Opción de Usuario: magit-update-other-window-delay

Retraso antes de actualizar automáticamente la otra ventana.

Al desplazarse por determinados búferes, entonces otros búferes, que se están visualizando en otra ventana, pueden actualizarse opcionalmente para mostrar información sobre la sección en el punto.

Al mantener pulsada una tecla para moverse por más de una sección, entonces eso actualizaría ese búfer para cada sección en el camino. Para evitarlo, la actualización del búfer de revisión se retrasa, y esta opción controla durante cuánto tiempo. Para una experiencia óptima puede que tenga que ajustar este retardo y/o la velocidad de repetición del teclado y el retardo de tu entorno gráfico o sistema operativo.

Visibilidad de las Secciones

Magit proporciona muchos comandos para cambiar la visibilidad de las secciones, pero todo lo que necesita para empezar son los dos siguientes.

TAB (TAB, magit-section-toggle)

Cambia (muestra u oculta) la visibilidad del cuerpo de la sección actual.

Ctrl-TAB (C-<tab>, magit-section-cycle)

Cicla entre la visibilidad de la sección actual y sus hijos.

Alt-TAB (M-<tab>, magit-section-cycle-diffs)

Cicla la visibilidad de las secciones relacionadas con diff en el búfer actual.

Shift-TAB (S-<tab>, magit-section-cycle-global)

Cicla la visibilidad de todas las secciones del búfer actual.

1 (magit-section-show-level-1)
2 (magit-section-show-level-2)
3 (magit-section-show-level-3)
4 (magit-section-show-level-4)
	

Muestra las secciones que rodean la sección actual hasta el nivel N.

M-1 (magit-section-show-level-1-all)
M-2 (magit-section-show-level-2-all)
M-3 (magit-section-show-level-3-all)
M-4 (magit-section-show-level-4-all)
	

Mostrar todas las secciones hasta el nivel N.

Algunas funciones, que se usan para implementar los comandos anteriores, también se exponen como comandos en sí mismos. Por defecto no hay teclas vinculadas a estos comandos, ya que generalmente se perciben como mucho menos útiles. Pero tu experiencia puede variar.

Comando: magit-section-show

Muestra el cuerpo de la sección actual.

Comando: magit-section-hide

Ocultar el cuerpo de la sección actual.

Comando: magit-section-show-headings

Muestra recursivamente los encabezados de los hijos de la sección actual. Sólo los encabezados. Los cuerpos de texto mostrados anteriormente se ocultan.

Comando: magit-section-show-children

Muestra recursivamente los cuerpos de los hijos de la sección actual. Con un argumento prefijo muestra los hijos hasta el nivel de la sección actual, y oculta los hijos más profundos.

Comando: magit-section-hide-children

Oculta recursivamente los cuerpos de los hijos de la sección actual.

Comando: magit-section-toggle-children

Alterna la visibilidad de los cuerpos de los hijos de la sección actual.

Cuando se crea un búfer por primera vez, algunas secciones se muestran expandidas mientras que otras no. Esto está codificado. Cuando se actualiza un búfer, se conserva la visibilidad anterior. La visibilidad inicial de ciertas secciones también se puede sobrescribir utilizando el gancho magit-section-set-visibility-hook.

Opción de Usuario: magit-section-initial-visibility-alist

Esta opción se puede usar para anular la visibilidad inicial de las secciones. En el futuro también se usará para definir los valores predeterminados, pero actualmente el valor predeterminado de una sección sigue estando codificado.

El valor es una lista. Cada elemento asigna un tipo de sección o linaje al estado de visibilidad inicial de dichas secciones. El estado debe ser uno de los siguientes: mostrar u ocultar, o una función que devuelva uno de estos símbolos. Se llama a una función con la sección como único argumento.

Use el comando magit-describe-section-briefly para determinar el linaje o tipo de una sección. El vector en la salida es el linaje de la sección y el tipo es el primer elemento de ese vector. Se pueden usar comodines, véase magit-section-match.

Opción de Usuario:

Esta opción controla para qué secciones se debe restaurar el estado de visibilidad anterior si una sección desaparece y más tarde vuelve a aparecer. El valor es un booleano o una lista de tipos de secciones. Si es t, se guarda en caché la visibilidad de todas las secciones. En caso contrario, sólo se hace para las secciones cuyo tipo coincide con uno de los tipos de la lista.

Esto requiere que la función magit-section-cached-visibility sea miembro de magit-section-set-visibility-hook.

Variable: magit-section-set-visibility-hook

Este gancho se ejecuta cuando se crea un búfer por primera vez y también cuando se actualiza un búfer existente, y se usa para determinar la visibilidad de la sección que se está insertando en ese momento.

Cada función se llama con un argumento, la sección que se está insertando. Debe devolver hide o show, o para dejar la visibilidad indefinida: nil. Si ninguna función decide sobre la visibilidad y el buffer se está refrescando, entonces se preserva la visibilidad; o si el buffer se está creando, entonces se usa el valor por defecto codificado.

Normalmente esto sólo debería usarse para establecer la visibilidad inicial, pero no durante las actualizaciones. Si magit-insert-section--oldroot es distinto de nil, entonces el búfer se está actualizando y estas funciones deberían devolver inmediatamente nil.

Opción de Usuario: magit-section-visibility-indicator

Esta opción controla si y cómo indicar que una sección puede expandirse/colapsarse.

Si es nil, no se muestra ningún indicador de visibilidad. En caso contrario, el valor debe tener una de estas dos formas:

• (EXPANDABLE-BITMAP . COLLAPSIBLE-BITMAP)
  Ambos valores tienen que ser variables cuyos valores sean bitmaps de franja. En este caso, cada sección que se pueda expandir o contraer tendrá un indicador en el margen izquierdo.
  Para proporcionar un relleno extra alrededor del indicador, establezca left-fringe-width en magit-mode-hook, por ejemplo:

  (add-hook 'magit-mode-hook (lambda ()
                               (setq left-fringe-width 20)))
  		

• (STRING . BOOLEAN)
  En este caso se muestra STRING (normalmente una elipsis) al final del encabezamiento de cada sección colapsada. Las secciones expandidas no reciben ningún indicador. El cdr controla si la aparición de estas elipsis tiene en cuenta el resaltado de las secciones. Hacerlo podría tener un impacto en el rendimiento, mientras que no hacerlo es un poco feo.

Sección Ganchos (Hooks)

Las secciones que se insertan en determinados búferes se controlan con ganchos. Esto incluye los buffers status y refs. Para otros buffers, por ejemplo, log y diff, esto no es posible. El comando magit-describe-section puede usarse para ver qué gancho (si lo hay) fue responsable de insertar la sección en cuestión.

Para buffers cuyas secciones pueden ser personalizadas por el Usuario, existe una variable hook llamada magit-TYPE-sections-hook. Este gancho debe cambiarse usando magit-add-section-hook. Evite usar add-hooks o la interfaz Custom.

Las distintas variables hook de sección disponibles se describen más adelante en este manual junto con las "funciones insertadoras de sección" correspondientes.

Función: magit-add-section-hook hook function &optional at append local

Añade la función FUNCTION al valor de la sección gancho HOOK.

Añade FUNCTION al principio de la lista de ganchos a menos que la opción APPEND no sea nula, en cuyo caso FUNCTION se añade al final. Si FUNCTION ya es un miembro entonces se mueve a la nueva ubicación.

Si el opcional AT no es nulo y es un miembro de la lista de ganchos, entonces añade FUNCTION junto a él. Añade antes o después de AT, o sustituye AT por FUNCTION dependiendo dez2 APPEND. Si APPEND es el símbolo replace, sustituye AT por FUNCTION. Para cualquier otro valor no nulo coloca FUNCTION justo después de AT. Si es nulo, coloca FUNCTION justo antes de AT. Si FUNCIÓN ya es un miembro de la lista pero AT no, entonces deja FUNCIÓN donde ya está.

Si LOCAL opcional no es nulo, entonces modifica el valor local del buffer del gancho en lugar de su valor global. Esto hace que el gancho sea local copiando el valor por defecto. Esa copia se modifica a continuación.

HOOK debe ser un símbolo. Si HOOK es void, primero se pone a nil. El valor de HOOK no debe ser una única función hook. FUNCTION debe ser una función que no toma argumentos e inserta una o múltiples secciones en un punto, desplazando el punto hacia adelante. FUNCTION puede elegir no insertar su(s) sección(es), cuando hacerlo no tenga sentido. No se debe abusar de ella para obtener otros efectos secundarios.

Para eliminar una función de un gancho de sección, use remove-hook.

Tipos y Valores de Sección

Cada sección tiene un tipo, por ejemplo hunk, file y commit. Las instancias de determinados tipos de sección también tienen un valor. El valor de una sección de tipo file, por ejemplo, es un nombre de archivo.

Por lo general, los Usuarios no tienen que preocuparse por el tipo y el valor de una sección, pero conocerlos puede ser útil en ocasiones.

H (H, magit-describe-section)

Este comando muestra información sobre la sección en el punto en un búfer separado.

Comando: magit-describe-section-briefly

Este comando muestra información sobre la sección en el punto del área de eco, como #<magit-section VALUE [TYPE PARENT-TYPE...] BEGINNING-END>.

Muchos comandos se comportan de manera diferente dependiendo del tipo de la sección en el punto y / o de alguna manera consumen el valor de esa sección. Pero esa es sólo una de las razones por las que la misma tecla puede hacer algo diferente, dependiendo de qué sección esté activa.

Además, para cada tipo de sección se puede definir un mapa de teclas, llamado magit-TYPE-section-map. Ese mapa de teclado se usa como mapa de teclado de propiedades de texto de todo el texto perteneciente a cualquier sección del tipo respectivo. Si dicho mapa no existe para un determinado tipo, puede definirlo usted mismo y se usará automáticamente.

Opciones de sección

En esta sección se describen las opciones que no sólo afectan a un tipo determinado de secciones. Como puede ver, no hay muchas.

Opción de Usuario: magit-section-show-child-count

Si se añade el número de hijos a los títulos de las secciones. Esto sólo afecta a las secciones que podrían beneficiarse de esta información.

Comandos Transitorios

Muchos comandos Magit se implementan como comandos transitorios. En primer lugar, el Usuario invoca un comando prefijo, que hace que sus argumentos infijos y comandos sufijos se muestren en el área de eco. A continuación, el Usuario opcionalmente algunos argumentos infijos y finalmente invoca uno de los comandos sufijos.

Esto se implementa en la biblioteca transient. Las versiones anteriores de Magit utilizaban el paquete magit-popup e incluso versiones anteriores la biblioteca magit-key-mode

Transient está documentado en (transient)Top.

Ctrl-x Alt-g (magit-dispatch)
Ctrl-c g (magit-dispach)

Este comando de prefijo transitorio vincula la mayoría de los otros comandos de prefijo de Magit como comandos de sufijo y los muestra en un búfer temporal hasta que se invoca uno de ellos. La invocación de un subprefijo de este tipo hace que se vinculen y muestren los sufijos de ese comando en lugar de los de magit-dispatch.

Este comando es también, o especialmente, útil fuera de los buffers de Magit, así que Magit por defecto lo vincula a Ctrl-c Alt-g (C-c M-g) en el mapa global de teclas. Ctrl-c g (C-c g) sería un mejor enlace, pero no podemos usarlo por defecto, porque esa secuencia de teclas está reservada para el Usuario. Vea Global Bindings para saber más sobre las combinaciones de teclas por defecto y recomendadas.

Argumentos transitorios y variables buffer

Los argumentos infijos de muchos de los comandos prefijo transitorios de Magit dejan de tener efecto una vez que el comando git al que se llama con esos argumentos ha vuelto. Los comandos que crean un commit son un buen ejemplo de esto. Si el Usuario cambia los argumentos, eso sólo afecta a la siguiente invocación de un comando sufijo. Si el mismo comando de prefijo transitorio se invoca de nuevo más tarde, entonces los argumentos se restablecen inicialmente al valor predeterminado. Este valor por defecto puede establecerse para la sesión actual de Emacs o guardarse permanentemente, ver (transient)Saving Values. También es posible recorrer los conjuntos de argumentos usados previamente usando Ctrl-Alt-p (C-M-p) y Ctrl-Alt-n (C-M-n), ver (transient)Using History.

Sin embargo, los argumentos infijos de muchos otros comandos transitorios continúan teniendo efecto incluso después de que el comando git que fue llamado con esos argumentos haya vuelto. Los comandos más importantes de este tipo son los que muestran un diff o log en un buffer dedicado. Obviamente, sus argumentos siguen teniendo efecto mientras se muestra el diff o log correspondiente. Además, los argumentos utilizados se almacenan en variables locales del buffer para futuras referencias.

Para los comandos del segundo grupo no siempre es deseable restablecer sus argumentos al valor global cuando se vuelve a invocar el comando de prefijo transitorio.

Como se mencionó anteriormente, es posible recorrer los conjuntos de argumentos utilizados anteriormente mientras una ventana emergente transitoria está visible. Esto significa que siempre podríamos restablecer los argumentos infijales al valor predeterminado porque el conjunto de argumentos que está activo en el búfer existente está a sólo unos Ctrl-Alt-p (C-M-p) de distancia. Magit puede configurarse para que se comporte así, pero como espero que la mayoría de los usuarios no lo encuentren muy conveniente, no es el valor por defecto.

También tenga en cuenta que es posible cambiar los argumentos diff y log usados en el buffer actual (incluyendo el buffer de estado, que contiene secciones diff y log) usando los respectivos comandos de prefijo transitorio "refresh" en D y L. (d y l por otro lado están pensados para cambiar qué diff o log se está mostrando. También es posible cambiar cómo se está mostrando el diff o log al mismo tiempo, pero si sólo quiere hacer esto último, entonces debería usar las variantes refresh). Debido a que estos prefijos secundarios de diff y log transitorios tratan de cambiar los argumentos usados en el buffer actual, siempre empiezan con el conjunto de argumentos que están actualmente en efecto en ese buffer.

Algunos comandos suelen invocarse directamente aunque también pueden invocarse como sufijo de un comando de prefijo transitorio. El más destacado es magit-show-commit, que suele invocarse tecleando Enter (RET) mientras point está en un commit en un log, pero también puede invocarse desde el prefijo transitorio magit-diff.

Cuando un comando de este tipo se invoca directamente, entonces es importante reutilizar los argumentos tal y como se especifican en los respectivos valores locales del buffer, en lugar de usar los argumentos por defecto. Imagine que pulsa Enter (RET) en un log para el commit en el punto en un buffer diferente y luego usa D (D) para cambiar cómo se muestra el diff en ese buffer. Luego pulsa Enter (RET) en otro commit para mostrar eso en su lugar y los argumentos del diff se restablecen a los predeterminados. No es resulta agradable; así que Magit no hace eso por defecto.

Opción de Usuario: magit-prefix-use-buffer-arguments

Esta opción controla si los argumentos infijos mostrados inicialmente en ciertos comandos de prefijo transitorio se basan en los argumentos que están actualmente en vigor en el buffer que actualizan sus sufijos.

Esta opción afecta a las órdenes de prefijo transitorio magit-diff y magit-log.

Opción de Usuario: magit-direct-use-buffer-arguments

Esta opción controla si ciertos comandos, cuando se invocan directamente (es decir, no como el sufijo de un comando de prefijo transitorio), usan los argumentos que están actualmente activos en el búfer que están a punto de actualizar. La alternativa es utilizar el valor por defecto para estos argumentos, lo que podría cambiar los argumentos que se utilizan en el buffer.

Los valores válidos para las dos opciones anteriores son:

• always: Usa siempre el conjunto de argumentos que esté activo en ese momento en el búfer correspondiente, siempre que ese búfer exista, por supuesto.
• selected o t: Usa el conjunto de argumentos del búfer respectivo, pero sólo si se muestra en una ventana del marco actual. Este es el valor por defecto para ambas variables.
• current: Usa el conjunto de argumentos del búfer respectivo, pero sólo si es el búfer actual.
  
• never: No usar nunca el conjunto de argumentos del búfer respectivo.

Me temo que la cosa se complica todavía más:

• Los argumentos globales diff y log se establecen individualmente para cada modo soportado. Los argumentos diff, por ejemplo, tienen valores diferentes en los búferes magit-diff-mode, magit-revision-mode, magit-merge-preview-mode y magit-status-mode. Establecer o guardar el valor para un modo no cambia el valor para otros modos. Sin embargo, el historial se comparte.
• Cuando magit-show-commit se invoca directamente desde un buffer de registro, entonces el filtro de fichero se recoge de ese buffer, no del buffer de revisión o de los argumentos diff del modo glogal.
• Aunque son sufijos del prefijo diff, magit-show-commit y magit-stash-show no usan el buffer diff usado por los comandos diff, en su lugar usan los buffers dedicados de revisión y stash.
  En el momento de invocar el prefijo diff, Magit desconoce cuál de los comandos sufijo va a llamar. Aunque no es seguro, lo más frecuente es que los Usuarios invoquen uno de los comandos que utilizan el buffer diff, por lo que los argumentos iniciales del infijo son los utilizados en ese buffer. Sin embargo, si llama uno de estos comandos directamente, entonces Magit sabe que debe usar los argumentos del buffer de revisión resp. stash.
• El prefijo log también incluye comandos reflog, pero estos comandos no utilizan los argumentos log.
• Si magit-show-refs se llama desde un búfer magit-refs-mode, entonces actúa como un prefijo de refresco y por lo tanto utiliza incondicionalmente los argumentos del búfer como argumentos iniciales. Si se invoca en otro lugar con un argumento de prefijo, entonces actúa como prefijo regular y por lo tanto respeta magit-prefix-use-buffer-arguments. Si se invoca en otro lugar sin un argumento de prefijo, entonces actúa como un comando directo y por lo tanto respeta magit-direct-use-buffer-arguments.

Finalización, Confirmación y Selección

Confirmación de acciones

Por defecto, muchas acciones que potencialmente podrían conducir a la pérdida de datos tienen que ser confirmadas. Esto incluye muchas acciones muy comunes, por lo que rápidamente puede llegar a ser molesto. Muchas de estas acciones se pueden deshacer y si has pensado en cómo deshacer ciertos errores, entonces debería ser seguro desactivar la confirmación para las acciones respectivas.

La opción magit-no-confirm puede usarse para decirle a Magit que realice ciertas acciones sin que el Usuario tenga que confirmarlas. Tenga en cuenta que, aunque esta opción sólo puede usarse para desactivar la confirmación de un conjunto específico de acciones, la siguiente sección explica otra forma de decirle a Magit que haga menos preguntas.

Opción de Usuario: magit-no-confirm

El valor de esta opción es una lista de símbolos, que representan acciones que no tienen que ser confirmadas por el Usuario antes de ser ejecutadas.

Por defecto, muchos comandos potencialmente peligrosos piden confirmación al Usuario. Cada uno de los siguientes símbolos representa una acción que, cuando se invoca involuntariamente o sin ser plenamente consciente de las consecuencias, podría provocar roturas. En muchos casos hay varios comandos que realizan variaciones de una determinada acción, por lo que no usamos los nombres de los comandos sino símbolos más genéricos.

• Aplicar cambios:
  • discard Descarta uno o más cambios (es decir, hunks o el diff completo de un fichero) pierde ese cambio, obviamente.
  • reverse Revertir uno o más cambios normalmente puede deshacerse revirtiendo la reversión.
  • stage-all-changes, unstage-all-changes: Cuando hay archivos añadidos o no al área de preparación, sacarlos de está área (staging area) destruiría esta acción. Por supuesto, esto también se aplica cuando se saca del area de preparación un único cambio, solo que se pierde menos y se hace tan a menudo que tener que confirmarlo cada vez sería inaceptable.
• Archivos:
  • delete Cuando se borra un archivo que aún no está siendo rastreado por Git, entonces se pierde por completo, no sólo los últimos cambios. Muy peligroso.
  • trash En lugar de borrar un archivo también se puede mover a la papelera del sistema. Obviamente mucho menos peligroso que borrarlo.
    Vea también la opción magit-delete-by-moving-to-trash
  • resurrect Un archivo borrado puede resucitarse fácilmente "borrando" el borrado, lo que se hace utilizando el mismo comando que se utilizó para borrar el mismo archivo en primer lugar.
  • untrack Se puede deshacer el rastreo de un archivo rastreándolo de nuevo.
  • rename Renombrar un fichero puede deshacerse fácilmente.
• Secuencias:
  • reset-bisect Abortar (conocido en Git como "resetear") una operación de bifurcación pierde toda la información recopilada hasta el momento.
  • abort-rebase Abortar un rebase elimina todos los commits ya modificados, pero es posible restaurarlos desde el reflog.
  • abort-merge Al abortar una fusión se eliminan todas las resoluciones de conflictos ya realizadas por el Usuario.
  • merge-dirty Fusionar con un árbol de trabajo sucio puede dificultar la vuelta al estado anterior al inicio de la fusión.
• Referencias:
  • delete-unmerged-branch Una vez que una rama ha sido eliminada, sólo puede ser restaurada utilizando herramientas de recuperación de bajo nivel proporcionadas por Git. E incluso entonces el reflog desaparece. El Usuario siempre tiene que confirmar la eliminación de una rama aceptando la opción por defecto (o seleccionando otra rama), pero cuando una rama aún no se ha fusionado, asegúrese también de que el Usuario es consciente de ello.
  • delete-pr-remote Al borrar una rama que fue creada a partir de un pull-request y si no existen otras ramas en esa remota, entonces magit-branch-delete ofrece borrar la remota también. Esto debería ser seguro porque sólo ocurre si no existen otras referencias en el espacio de nombres de las remotas, y puede recrear la remota si es necesario.
  • drop-stashes Eliminar un stash es peligroso porque Git almacena stashes en el reflog. Una vez que se elimina un stash, no hay vuelta atrás sin utilizar las herramientas de recuperación de bajo nivel proporcionadas por Git. Cuando se elimina un único stash, el usuario siempre tiene que confirmar aceptando el valor por defecto (o seleccionando otro). Esta acción sólo afecta a la eliminación de varios stashes a la vez.
• Publicación:
  • set-and-push Cuando se empuja al upstream o al push-remote y eso no está realmente configurado todavía, entonces el Usuario puede establecer primero el objetivo. Si Él/Ella confirma el valor por defecto demasiado rápido, podrían terminar enviando a la rama equivocada y si el repositorio remoto está configurado para no permitir la corrección de tales errores, entonces eso puede ser bastante embarazoso y molesto.
• Editar historial publicado:
  Sin añadir estos símbolos aquí, se le advertirá antes de editar confirmaciones (commits) que ya han sido empujados a una de las ramas listadas en magit-published-branches.
  • amend-published Afecta a la mayoría de los comandos que modifican a "HEAD".
  • rebase-published Afecta a los comandos que realizan rebases interactivos. Esto incluye comandos del commit transient que modifican un commit distinto de "HEAD", es decir, las diversas variantes de fixup y squash.
  • edited-published Affects the commands magit-edit-line-commit y magit-diff-edit-hunk-commit Estos dos comandos hacen que sea bastante fácil editar accidentalmente una confirmacion publicada, por lo que debería pensarlo dos veces antes de configurarlos para que no pidan confirmación.
  Para desactivar completamente la confirmación, añada aquí los tres símbolos o establezca magit-published-branches a nil.
• Varios:
  • kill-process Rara vez hay una razón para matar a un proceso.
• Configuración global:
  En lugar de añadir todos los símbolos anteriores al valor de esta opción, también puede establecerla en el átomo ‘t’, que tiene el mismo efecto que añadir todos los símbolos anteriores. Hacer eso es ciertamente una mala idea, especialmente porque otros símbolos podrían ser añadidos en el futuro. Así que incluso si no quiere que se le pida confirmación para ninguna de estas acciones, es mejor que añada todos los símbolos respectivos individualmente.
  Cuando magit-wip-before-change-mode está habilitado, las siguientes acciones pueden deshacerse fácilmente: discard, reverse, stage-all-changes y unstage-all-changes. Sólo si este modo está activado safe-with-wip tiene el mismo efecto que añadir todos estos símbolos individualmente.

Finalización y confirmación

Muchos comandos Magit piden al Usuario que seleccione entre una lista de posibles acciones, ofreciendo la opción más probable como predeterminada. Para muchos de estos comandos, el valor predeterminado es la cosa en el punto, siempre que realmente sea una cosa válida sobre la que actuar. Para muchos comandos que actúan sobre una rama, la rama actual sirve por defecto si no hay rama en el punto.

Estos comandos combinan la petición de confirmación y la petición de un objetivo sobre el que actuar en una única acción. El Usuario puede confirmar el objetivo por defecto utilizando RETURN (RET) o abortar utilizando Ctrl-g (C-g). Esto es similar a un prompt y-or-n-p, pero las teclas para confirmar o abortar difieren.

Al mismo tiempo, el Usuario también tiene la oportunidad de seleccionar otro objetivo, lo cual es útil porque para algunos comandos y/o en algunas situaciones es posible que desee seleccionar la acción antes de seleccionar el objetivo moviéndose hacia él.

Sin embargo, es posible que para algunos comandos siempre quiera utiliza el objetivo predeterminado, si lo hay, o incluso que quiera que el comando actúe sobre el predeterminado sin requerir confirmación alguna. La opción magit-dwim-selection puede utilizarse para configurar ciertos comandos a tal efecto.

Tenga en cuenta que cuando la región está activa, muchos comandos actúan sobre las cosas seleccionadas utilizando un mecanismo basado en la región, en muchos casos después de pedir confirmación. Este mecanismo basado en la región se denomina "selección" y se describe en detalle en la siguiente sección. Cuando existe una selección que es válida para el comando invocado, entonces ese comando nunca ofrece actuar sobre otra cosa, y si pide confirmación no está controlado por esta opción.

Tenga en cuenta también que Magit pide confirmación de ciertas acciones que no están asociadas a la finalización (o a la selección). Estos diálogos tampoco se ven afectados por esta opción y se describen en la sección anterior.

Opción de Usuario: magit-dwim-selection

Esta opción puede utilizarse para indicar a determinados comandos que utilicen la cosa en cuestión en lugar de pedir al Usuario que seleccione un candidato sobre el que actuar, con o sin confirmación.

El valor tiene la siguiente forma ((COMMAND nil|PROMPT DEFAULT)...)

• COMANDO es el comando que no debe pedir una elección. Para que tenga efecto, el comando tiene que usar la función magit-completing-read o una función de utilidad que a su vez use esa función.
• Si el comando utiliza magit-completing-read varias veces, entonces PROMPT puede usarse para afectar sólo a uno de estos usos. PROMPT, si no es nulo, es una expresión regular que se utiliza para comparar con el argumento PROMPT pasado a magit-completing-read.
• DEFAULT especifica cómo utilizar el valor por defecto. Si es t, entonces el argumento DEFAULT pasado a magit-completing-read se utiliza sin confirmación. Si es ask, se da al Usuario la oportunidad de abortar. DEFAULT también puede ser nil, en cuyo caso la entrada no tiene efecto.

La Selección

Si la región está activa, muchos comandos Magit actúan sobre las cosas seleccionadas utilizando un mecanismo basado en la región en lugar de en una sola cosa. Cuando la región no está activa, estos comandos actúan sobre el objeto en cuestión o leen un único objeto sobre el que actuar. Esto se describe en la sección anterior - esta sección sólo cubre cómo se seleccionan múltiples cosas, cómo se visualiza, y cómo ciertos comandos se comportan cuando ese es el caso.

El mecanismo de Magit para seleccionar múltiples cosas, o más bien secciones que representan estas cosas, se basa en la región de Emacs, pero el área que Magit considera seleccionada es normalmente mayor que la región y se aplican restricciones adicionales.

Magit distingue entre una región que cumple los requisitos para formar una selección Magit válida y una región que no los cumple. Si la región no cumple los requisitos, entonces se visualiza como en otros buffers de Emacs. Si la región sí cumple los requisitos para formar una selección Magit, entonces la selección siempre se visualiza, mientras que la región en sí sólo se visualiza si empieza y acaba en la misma línea.

Para que una región pueda considerarse una selección Magit, debe comenzar en el encabezamiento de una sección y terminar en el encabezamiento de una sección hermana. Tenga en cuenta que si el final de la región está al principio del encabezamiento de una sección (es decir, al principio de una línea), se considera que esa sección está dentro de la selección.

Esto no es consistente con la forma en que la región se trata normalmente en Emacs - si la región termina al principio de una línea, entonces esa línea está fuera de la región. Debido a cómo Magit visualiza la selección, debería ser obvio que existe esta diferencia.

No todos los comandos actúan sobre todas las selecciones válidas. Algunos comandos ni siquiera tienen en cuenta la ubicación del punto, otros pueden actuar sobre la sección en el punto pero no pueden actuar sobre la selección, e incluso los comandos que sí pueden actuar sobre la selección sólo lo hacen si ésta selecciona cosas sobre las que pueden actuar.

Esta es la razón principal por la que la selección debe incluir la sección en el punto. Incluso si existe una selección, el comando invocado puede ignorarla, en cuyo caso puede actuar sólo sobre la sección actual. Es mucho más seguro actuar sólo sobre la sección actual pero no sobre las otras secciones seleccionadas que actuar sobre la sección actual en lugar de sobre las secciones seleccionadas. Esto último sería mucho más sorprendente y si la sección actual siempre forma parte de la selección, entonces eso no puede ocurrir.

Variable: magit-keep-region-overlay

Esta variable controla si la región se visualiza de la forma habitual incluso cuando existe una selección Magit válida o una región interna a la búsqueda. Consulte el doc-string para obtener más información.

La Región de una Parte Interna

Algo relacionada con la selección Magit descrita en la sección anterior está la región interna de búsqueda.

Al igual que la selección, la región de búsqueda interna se basa en la región Emacs pero hace que esa región no se visualice como lo haría en otros buffers Emacs, e incluye la línea en la que termina la región incluso si termina al principio de esa línea.

A diferencia de la selección, que se basa en una región que debe comenzar en el encabezamiento de una sección y terminar en la sección de una sección hermana, la región interna de un trozo debe comenzar dentro del cuerpo de una sección de un trozo y terminar en el cuerpo de la misma sección.

La región interna del trozo es respetada por los comandos "apply", que pueden, entre otros objetivos, actuar sobre un trozo. Si la región interna de la pieza está activa, estos comandos actúan sólo sobre la parte marcada de la pieza en lugar de sobre la pieza completa.

El Minibuffer

El minibuffer es el lugar donde los comandos de Emacs leen los argumentos complicados, como: nombres de archivos, nombres de los buffers, nombres de las ordenes del Editor o las expresiones de Lisp. Lo llamamos "minibuffer" porque es un buffer de propósito especial con una pequeña cantidad de espacio en pantalla. En este espacio, puede usar los comandos de edición habituales de Emacs para editar el texto del argumento.

Soporte para Marcos de Autocompletado

La opción incorporada completing-read-function especifica la función de bajo nivel utilizada por completing-read para pedir al Usuario que seleccione de una lista de opciones. Su valor por defecto es completing-read-default. Los marcos de compleción alternativos suelen activarse sustituyendo su propia implementación.

Por razones históricas Magit proporciona una opción similar llamada magit-completing-read-function, que sólo controla la función de bajo nivel usada por magit-completing-read. Esta opción también hace posible usar un mecanismo de completado diferente para Magit que para el resto de Emacs, pero no es recomendable hacerlo.

Lo más probable es que no tenga que personalizar la opción específica de magit para usar un marco de compleción alternativo. Por ejemplo, si activa ivy-mode, entonces Magit lo respetará, y si activa helm-mode, también.

Sin embargo, si quiere usar Ido, entonces ido-mode no funcionará. También tendrá que instalar el paquete ido-completing-read+ y usar magit-ido-completing-read como magit-completing-read-function.

Opción de Usuario: magit-completing-read-function

El valor de esta variable es la función de bajo nivel utilizada para realizar el autocompletado por el código que usa magit-completing-read (en oposición a completing-read incorporado).

El valor por defecto, magit-builtin-completing-read, es adecuado al menos para el mecanismo de completado estándar, ivy-mode y helm-mode.

Los valores incorporados completing-read y completing-read-default no son adecuados para ser usados aquí. magit-builtin-completing-read realiza algún trabajo adicional, y cualquier función usada en su lugar tiene que hacer lo mismo.

Función: magit-builtin-completing-read opciones de prompt &opcional implica require-match initial-input hist def

Esta función realiza la finalización utilizando la función incorporada completing-read y realiza algunas tareas adicionales específicas de magit.

Función: magit-ido-completing-read opciones de prompt &opcional implica require-match initial-input hist def

Esta función lleva a cabo la finalización usando ido-completing-read+ del paquete del mismo nombre (que tiene que instalar explícitamente) y hace algún trabajo adicional específico de magit.

Tenemos que usar ido-completing-read+ en lugar de ido-completing-read que viene con el propio Ido, porque este último, aunque está pensado como un reemplazo directo, no puede servir para ese propósito porque viola demasiadas de las convenciones implícitas.

Función: magit-completing-read opciones de prompt &opcional implica require-match initial-input hist def fallback

Esta es la función que usan los comandos Magit cuando necesitan que el Usuario seleccione una única cosa sobre la que actuar. Los argumentos tienen el mismo significado que para completing-read, excepto FALLBACK, que es exclusivo de esta función y se describe a continuación.

En lugar de pedir al Usuario que elija de una lista de posibles candidatos, esta función puede simplemente devolver el valor por defecto especificado por DEF, con o sin requerir la confirmación del Usuario. Si este es el caso depende de PROMPT, this-command y magit-dwim-selection. Consulta la documentación de este último para obtener más información.

Si lee un valor en el minibuffer, entonces esta función actúa de forma similar a completing-read, excepto por lo siguiente:

• COLLECTION debe ser una lista de opciones. No se admite una función.
• Si REQUIRE-MATCH es nulo (nil), y el Usuario sale sin elegir, entonces se devuelve nil en lugar de una cadena vacía.
• Si REQUIRE-MATCH es no nulo, y el usuario sale sin elegir, se produce un error de Usuario.
• FALLBACK por defecto especifica un valor secundario que sólo se usa si el valor por defecto primario DEF es . El valor secundario por defecto no está sujeto a magit-dwim-selection - si DEF es nil pero FALLBACK no lo es, entonces esta función siempre pide al Usuario que elija un candidato, igual que si ambos valores por defecto fueran nulos.
• ": "se añade al PROMPT.
• PROMPT se modifica para terminar con \" (por defecto DEF|FALLBACK): \" siempre que DEF o FALLBACK no sean nulos, que ni ivy-mode ni helm-mode estén activados, y que magit-completing-read-function tenga el valor por defecto magit-builtin-completing-read.

Opciones Adicionales de Autocompletado

Opción de Usuario: magit-list-refs-sortby

Para muchos comandos que leen una o varias refs del Usuario, el valor de esta opción puede usarse para controlar el orden de las refs. Los valores válidos incluyen cualquier clave aceptada por la opción --sort de git for-each-ref. Por defecto, las refs se ordenan alfabéticamente por su nombre completo (por ejemplo, "refs/heads/master").

Soporte para el Ratón

Haciendo doble clic en el encabezamiento de una sección se conmuta la visibilidad de su cuerpo, si lo hubiera. Del mismo modo, si se hace clic en la franja izquierda, se cambia la visibilidad de la sección correspondiente.

Se proporciona un menú contextual, pero debe habilitarse explícitamente. En Emacs 28 y posteriores, activa el modo global context-menu-mode. Si usa una versión anterior de Emacs, active magit-section-show-context-menu-for-emacs<28.

Ejecución de Git

Visualización de la salida de Git

Magit ejecuta Git ya sea por efectos secundarios (por ejemplo, al hacer push) o para obtener algún valor (por ejemplo, el nombre de la rama actual).

Cuando Git se ejecuta por efectos secundarios, la salida del proceso se registra en un buffer de registro por repositorio, que puede consultarse usando el comando magit-process cuando las cosas no van como se esperaba.

Se conserva la salida/errores de hasta ‘magit-process-log-max’ comandos Git.

$ ($, magit-process)

Este comando muestra el buffer de procesos para el repositorio actual.

Dentro de ese búfer, están disponibles los atajos de teclado habituales para navegar y mostrar secciones. Hay un comando adicional.

k (k, magit-process-kill)

Este comando mata el proceso representado por la sección en el punto.

Variable: magit-git-debug

Esta opción controla si se habilita la notificación adicional de errores de git.

Magit básicamente llama a git por una de estas dos razones: por efectos secundarios o para hacer algo con su salida estándar.

Cuando git se ejecuta por efectos secundarios, su salida, incluyendo los mensajes de error, van al buffer del proceso que se muestra cuando se usa $.

Cuando por alguna razón la salida de git se consume, sería bastante costoso insertarla también en este buffer, pero cuando esta opción no es nula y git vuelve con un estado de salida distinto de cero, al menos su error estándar se inserta en este buffer.

Esto es sólo para propósitos de depuración. No lo active de forma permanente, ya que afectaría negativamente al rendimiento.

Esto es sólo para propósitos de depuración. No lo habilite permanentemente, afectaría negativamente al rendimiento. Tenga en cuenta también que el hecho de que git salga con un estado de salida distinto de cero e imprima un mensaje de error, normalmente no significa que sea un error en lo que concierne a Magit, que es otra de las razones por las que normalmente ocultamos estos mensajes de error. Si un mensaje de error es relevante en el contexto de un comportamiento inesperado debe juzgarse caso por caso.

El comando magit-toggle-git-debug cambia el valor de esta variable.

Variable: magit-process-extreme-logging

Esta opción controla si magit-process-file registra en el buffer *Messages*.

Sólo está pensada para un uso temporal cuando intentes averiguar cómo Magit usa Git entre bastidores. La salida que normalmente va al buffer magit-process continúa yendo allí. No toda la salida va a cualquiera de estos dos buffers.

Estado del proceso Git

Cuando un proceso Git se está ejecutando por efectos secundarios, Magit muestra un indicador en la línea de modo, usando la cara magit-mode-line-process.

Si el proceso Git sale con éxito, el indicador de proceso se elimina de la línea de modo inmediatamente.

En el caso de un error de Git, el indicador de proceso no se elimina, sino que se resalta con la cara magit-mode-line-process-error, y los detalles del error del búfer de proceso se proporcionan como información sobre herramientas para los usuarios del ratón. Este indicador de error persiste en la línea de modo hasta la siguiente actualización de la memoria intermedia de magit.

Si no desea que los errores de proceso se indiquen en la línea de modo, personalice la opción de usuario magit-process-display-mode-line-error.

Los errores de proceso se indican adicionalmente en la parte superior del búfer de estado.

Ejecutando Git manualmente

Aunque Magit proporciona muchos comandos Emacs para interactuar con Git, no lo cubre todo. En esos casos, su conocimiento de Git le será útil. Magit proporciona algunos comandos para ejecutar comandos Git arbitrarios escribiéndolos en el minibuffer, en lugar de tener que cambiar a una shell.

! (!, magit-run)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

!! (! !, magit-git-command-topdir)

Este comando lee un comando del Usuario y lo ejecuta en el directorio de nivel superior del árbol de trabajo actual.

La cadena "git " se usa como entrada inicial cuando se solicita al Usuario el comando. Se puede eliminar para ejecutar otro comando.

!p (! p, magit-git-command)

Este comando lee un comando del Usuario y lo ejecuta en el directorio por defecto. Con un argumento prefijo, el comando se ejecuta en el directorio de nivel superior del árbol de trabajo actual.

La cadena "git " se usa como entrada inicial cuando se pide al Usuario el comando. Puede eliminarse para ejecutar otro comando.

!s (! s, magit-shell-command-topdir)

Este comando lee un comando del Usuario y lo ejecuta en el directorio de nivel superior del árbol de trabajo actual.

!S (! S, magit-shell-command)

Este comando lee un comando del Usuario y lo ejecuta en el directorio por defecto. Con un argumento de prefijo, el comando se ejecuta en el directorio de nivel superior del árbol de trabajo actual.

Opción de Usuario: magit-shell-command-verbose-prompt

Si el prompt, utilizado por los comandos anteriores cuando se lee un comando shell, muestra el directorio en el que se ejecutará.

Estos comandos de sufijo inician herramientas gui externas.

!k (! K, magit-run-gitk)

This command runs gitk in the current repository.

!a (! a, magit-run-gitk-all)

Este comando ejecuta gitk --all en el repositorio actual.

!b (! b, magit-run-gitk-branches)

Este comando ejecuta gitk --branches en el repositorio actual.

!g (! g, magit-run-git-gui)

Este comando ejecuta git gui en el repositorio actual.

!m (! m, magit-git-mergetool)

Este comando ejecuta ‘git mergetool --gui’ en el repositorio actual.

Con un argumento prefijo actúa como un comando prefijo transitorio, permitiendo al Usuario seleccionar el mergetool y cambiar algunos ajustes.

Ejecutable de Git

Cuando Magit llama a Git, puede hacerlo usando la ruta absoluta al ejecutable de git, o usando sólo su nombre.

Cuando se ejecuta git localmente y el sistema (system-type) es windows-nt (cualquier versión de Windows) o darwin (macOS), magit-git-executable se establece en una ruta absoluta cuando se carga Magit.

En Windows es necesario usar una ruta absoluta porque Git viene con varios scripts de envoltura para el binario real, que también se colocan en $PATH, y el uso de una de estas envolturas en lugar del binario degradaría el rendimiento horriblemente. Para algunos usuarios de macOS usar sólo el nombre del ejecutable también tiene un rendimiento horrible, así que evitamos hacerlo en esa plataforma también. En otras plataformas, usar sólo el nombre parece funcionar bien.

Usar una ruta absoluta cuando se ejecuta git en una máquina remota sobre Tramp, sería una situación problemática usar una ruta absoluta que sea adecuada en la máquina local, por lo que se usa una opción separada para controlar el nombre o la ruta que se usa en las máquinas remotas.

Opción de Usuario: magit-git-executable

El ejecutable git usado por Magit en el host local. Debería ser la ruta absoluta al ejecutable, o la cadena "git" para permitir a Emacs encontrar el ejecutable por sí mismo, usando el mecanismo estándar para hacer tales cosas.

Opción de Usuario: magit-remote-git-executable

El ejecutable git usado por Magit en máquinas remotas a través de Tramp. Normalmente debería ser sólo la cadena "git". Considere personalizar tramp-remote-path en lugar de esta opción.

Puede evitar que Emacs sea incapaz de encontrar el ejecutable correcto estableciendo explícitamente el valor de una de estas dos opciones. Hacer eso debería considerarse una chapuza; es mejor asegurarse de que el orden en exec-path o tramp-remote-path es correcto.

Tenga en cuenta que exec-path se establece basándose en el valor de la variable de entorno PATH que está activa cuando se inicia Emacs. Si establece PATH en los ficheros init de su shell, sólo tendrá efecto en Emacs si lo inicia desde esa shell (porque el entorno de un proceso sólo se pasa a sus procesos hijos, no a otros procesos arbitrarios). Si no es así como arranca Emacs, entonces el paquete exec-path-from-shell puede ayudar; aunque honestamente también lo considero una chapuza.

El comando magit-debug-git-executable puede ser útil para averiguar dónde está buscando Emacs git.

M-x magit-debug-git-executable

Este comando muestra un buffer con información sobre magit-git-executable y magit-remote-git-executable.

M-x magit-versión

Este comando muestra las versiones actualmente usadas de Magit, Git y Emacs en el área de eco. De forma no interactiva sólo devuelve la versión de Magit.

Argumentos Gobales de Git

Opción de Usuario: magit-git-global-arguments

Los argumentos establecidos aquí se usn cada vez que el ejecutable git se dispara como un subproceso. Se colocan justo después del propio ejecutable y antes del comando git - como en git HERE... COMMAND REST. Para conocer los argumentos válidos, consulta la página de manual de git(1).

Tenga cuidado con lo que añade aquí, especialmente si está usando Tramp para conectarse a servidores con versiones antiguas de Git. Nunca elimine nada que sea parte del valor por defecto, a menos que realmente sepa lo que está haciendo. Y piense muy bien antes de añadir algo; se usará cada vez que Magit ejecute Git para cualquier propósito.

Inspección

La funcionalidad que ofrece Magit puede dividirse a grandes rasgos en tres grupos: inspección de datos existentes, manipulación de datos existentes o adición de nuevos datos, y transferencia de datos. Por supuesto, se trata de una distinción bastante burda que a menudo se queda corta, pero es más útil que no hacer ninguna distinción. Esta sección trata de la inspección de datos, las dos siguientes de su manipulación y transferencia. Luego sigue una sección sobre funcionalidades varias, que no pueden encajar fácilmente en esta distinción.

Por supuesto, otras distinciones también tienen sentido, por ejemplo, la distinción de Git entre comandos de porcelana y de fontanería, que en su mayor parte es equivalente a la distinción de Emacs entre comandos interactivos y funciones no interactivas. Todas las secciones mencionadas anteriormente se ocupan principalmente de la porcelana - la capa de fontanería de Magit se describe más adelante.

Búfer de estado

Mientras que otros buffers de Magit contienen, por ejemplo, un diff en particular o un log en particular, el buffer de estado contiene los diffs para cambios preparados o no, logs para commits no empujados y no empujados, listas de trabajos guardados rápidos stashes y archivos sin seguimiento, e información relacionada con la rama actual.

Durante ciertas operaciones incompletas - por ejemplo, cuando una fusión resulta en un conflicto - se muestra información adicional que ayuda a continuar o abortar la operación.

El comando magit-status muestra el búfer de estado perteneciente al repositorio actual en otra ventana. Este comando se usa tan a menudo que debería estar vinculado globalmente. Recomendamos usar Ctrl-x g (C-x g):

(global-set-key (kbd "C-x g") 'magit-status)

Ctrl-x g (C-x g, magit-status)

Cuando se invoca desde un repositorio Git existente, este comando muestra el estado de ese repositorio en un buffer.

Si el directorio actual no se encuentra dentro de un repositorio Git, entonces este comando solicita un repositorio existente o un directorio arbitrario, dependiendo de la opción magit-repository-directories, y en su lugar se muestra el estado del repositorio seleccionado.

• Si esa opción especifica algún repositorio existente, se pide al Usuario que seleccione uno de ellos.
• De lo contrario, se le pide al Usuario que seleccione un directorio arbitrario uso la función normal de completar nombres de archivo. Si el directorio seleccionado es el directorio de nivel superior de un árbol de trabajo existente, se muestra el búfer de estado correspondiente.
• En caso contrario, se ofrece al Usuario inicializar el directorio seleccionado como un nuevo repositorio. Después de crear el repositorio se muestra su búfer de estado.

Estos comportamientos alternativos también pueden forzarse usando uno o más argumentos de prefijo:

• Con dos argumentos de prefijo (o, más exactamente, un valor numérico de prefijo igual o superior a 16) se lee un directorio arbitrario, sobre el que se actúa como se ha descrito anteriormente. Lo mismo podría conseguirse usando la orden magit-init.
• Con un único argumento de prefijo se lee un repositorio de Usuario existente, o si no se puede encontrar ningún repositorio basándose en el valor de magit-repository-directories, entonces el comportamiento es el mismo que con dos argumentos de prefijo.

Opción de Usuario magit-repository-directories

Lista de directorios que son repositorios Git o contienen repositorios Git.

Cada elemento tiene la forma (DIRECTORIO . PROFUNDIDAD). DIRECTORY tiene que ser un directorio o un nombre de archivo de directorio, una cadena. DEPTH, un entero, especifica la profundidad máxima de búsqueda de repositorios Git. Si es 0, sólo se añade el propio DIRECTORIO.

Esta opción controla qué repositorios son listados por magit-list-repositories. También afecta a magit-status (que ver) de formas potencialmente sorprendentes (ver más arriba).

Opción de Usuario: magit-status-quick

Este comando es una alternativa a magit-status que normalmente evita refrescar el buffer de estado.

Si el búfer de estado del repositorio Git actual existe pero no se está mostrando en el marco seleccionado, entonces se muestra sin ser refrescado.

Si el búfer de estado se está mostrando en el fotograma seleccionado, este comando lo refresca.

Los argumentos prefijados tienen el mismo significado que para magit-status y, además, hacen que se refresque el búfer.

Para usar este comando añada esto a su archivo init:

(global-set-key (kbd "C-x g") 'magit-status-quick).

Si hace eso y luego por una vez quiere volver a mostrar el buffer y también refrescarlo inmediatamente, pulse Ctrl-x g (C-x g) seguido de g (g).

Un posible comando alternativo es magit-display-repository-buffer. Permite mostrar cualquier búfer Magit existente que pertenezca al repositorio actual; no sólo el búfer de estado.

Comando: ido-enter-magit-status

Desde un prompt de Ido usado para abrir un archivo, en su lugar se suelta en magit-status. Esto es similar a ido-magic-delete-char, que, a pesar de su nombre, normalmente provoca la creación de un buffer Dired.

Para que este comando esté disponible, use:

(add-hook 'ido-setup-hook
          (lambda ()
            (define-key ido-completion-map
              (kbd \"C-x g\") 'ido-enter-magit-status)))
	

A partir de Emacs 25.1 los mapas de teclado de Ido se definen sólo una vez en lugar de cada vez que se invoca a Ido, así que ahora puedes modificarlo como cualquier otro mapa de teclado:

(define-key ido-common-completion-map
  (kbd \"C-x g\") 'ido-enter-magit-status)
	

Secciones de estado

El contenido de los buffers de estado se controla mediante el hook magit-status-sections-hook. Consulte Sección Ganchos (Hooks) para obtener más información sobre estos ganchos y cómo personalizarlos.

Opción de Usuario: magit-status-sections-hook

Gancho ejecutado para insertar secciones en un búfer de estado.

La primera función de ese gancho (hook) por defecto es magit-insert-status-headers; se describe en la siguiente sección. Por defecto, las siguientes funciones también son miembros de ese hook:

Función: magit-insert-merge-log

Inserta sección para la fusión en curso. Muestra las cabeceras que se están fusionando. Si no hay ninguna fusión en curso, no hace nada.

Funcion: magit-insert-rebase-sequence

Inserta sección para la secuencia de rebase en curso. Si no hay ninguna secuencia en curso, no hace nada.

Función: magit-insert-am-sequence

Inserta sección para la secuencia de aplicación de parches en curso. Si no hay ninguna secuencia en curso, no hace nada.

Función: magit-insert-sequencer-sequence

Inserta sección para la secuencia seleccionada en curso o revierte dicha selección. Si no hay ninguna secuencia en curso, no hace nada.

Funcion: magit-insert-bisect-output

Durante la bisección, inserta la sección con la salida de git bisect.

Función: magit-insert-bisect-rest

Mientras divide en dos partes (bisecta), inserta la sección visualizando el estado de bisección.

Función: magit-insert-bisect-log

Mientras divide en dos secciones (bisecta), inserta la sección que registra el progreso de la bisección.

Función: magit-insert-untracked-files

Es posible que este comando inserte una lista o árbol de archivos sin seguimiento.

Hágalo dependiendo del valor de status.showUntrackedFiles. Tenga en cuenta que incluso si el valor es all, Magit sigue mostrando inicialmente sólo directorios. Pero las secciones de directorios pueden expandirse usando TAB.

Función: magit-insert-unstaged-changes

Inserta sección mostrando cambios no preparados (changed unstaged).

Función: magit-insert-staged-changes

Inserta sección que muestre los cambios preparados.

Función: magit-insert-stashes &opcional referencias de las cabeceras (ref heading)

Inserta la sección de stashes (la sección de cambios confirmados) mostrando reflog para "refs/stash". Si el REF opcional no es nulo, muestra el reflog de ese en su lugar. Si el encabezado opcional HEADING no es nulo, uselo como encabezado de sección en lugar de "Stashes:".

Función: magit-insert-unpulled-from-upstream

Inserta una sección que muestra las confirmaciones (commits) que aún no han sido extraídos de la rama remota (upstream).

Función: magit-insert-unpulled-from-pushremote

Inserta una sección que muestra las confirmaciones (commits) que aún no se han extraído de la rama push-remote.

Función: magit-insert-unpushed-to-upstream

Insertar una sección que muestra las confirmaciones (commits) que aún no se han enviado a la rama remota (upstream).

Función: magit-insert-unpushed-to-pushremote

Inserta sección mostrando las confirmaciones (commits) que aún no han sido empujados al push-remote.

También se pueden añadir las siguientes funciones al gancho anterior:

Función: magit-insert-tracked-files

Inserta un árbol de archivos rastreados.

Función: magit-insert-ignored-files

Inserta un árbol de archivos ignorados. Es posible limitar los registros en el búfer actual a un directorio determinado utilizando D = f <DIRECTORIO> RET g. Si lo hace, entonces que también afecta a este comando.

El filtro de registro se puede usar para limitar a varios archivos. En ese caso esta función sólo respeta el primero de los ficheros y sólo si es un directorio.

Función: magit-insert-skip-worktree-files

Inserta un árbol de archivos skip-worktree. Si el primer elemento de magit-buffer-diff-files es un directorio, entonces limita la lista a los archivos situados por debajo de él. El valor de esa variable puede establecerse usando D -- DIRECTORY RET g.

Función: magit-insert-assumed-unchanged-files

Inserta un árbol de archivos que se suponen inalterados. Si el primer elemento de magit-buffer-diff-files es un directorio, entonces limita la lista a los archivos situados por debajo de él. El valor de esa variable puede establecerse usando D -- DIRECTORY RET g.

Función: magit-insert-unpulled-or-recent-commits

Inserta sección mostrando confirmaciones (commits) no extraídas o recientes. Si hay una rama remota (upstream) configurado para la rama actual que está por delante, muestra las confirmaciones que faltan. Si no, muestra los últimos commits de magit-log-section-commit-count.

Función: magit-insert-recent-commits

Inserta sección mostrando las últimas confirmaciones (commits) de magit-log-section-commit-count.

Opción de Usuario: magit-log-section-commit-count

Cuántas confirmaciones (commits) recientes muestran magit-insert-recent-commits y magit-insert-unpulled-or-recent-commits (siempre y cuando no hayan confirmaciones sin enviar o empujar (commits unpulled)).

Función: magit-insert-unpulled-cherries

Inserta sección mostrando confirmaciones no empujadas. Como magit-insert-unpulled-commits, pero anteponiendo "+" a cada confirmación que aún no se haya aplicado (es decir, una confirmación con un patch-id no compartido con ninguna confirmación en la rama remota), y "-" a todas las demás.

Función: magit-insert-unpushed-cherries

Inserta sección mostrando confirmaciones no aplicadas. Como magit-insert-unpushed-commits, pero anteponiendo "+" a cada confirmación que aún no se ha aplicado al flujo ascendente (es decir, una confirmación con un patch-id no compartido con ninguna confirmación del flujo ascendente) y "-" a todas las demás.

Vea Buffer de Referencias para algunos insertadores de sección más, que podrían ser usados aquí.

Secciones: Cabeceras de Estado

El contenido de los búferes de estado se controla mediante el gancho magit-status-sections-hook (véase Secciones de estado).

Por defecto magit-insert-status-headers es el primer miembro de esa variable de gancho.

Función: magit-insert-status-headers

Inserta secciones de cabecera apropiadas para los buffers magit-status-mode. Las secciones se insertan ejecutando las funciones del gancho magit-status-headers-hook.

Opción de Usuario: magit-status-headers-hook

Gancho que se ejecuta para insertar secciones de cabecera en el búfer de estado.

Este gancho es ejecutado por magit-insert-status-headers, que a su vez tiene que ser miembro de magit-status-sections-hook para ser usado.

Por defecto, las siguientes funciones son miembros del gancho anterior:

Función: magit-insert-error-header

Inserta una línea de cabecera mostrando el mensaje sobre el error Git que acaba de ocurrir.

Esta función sólo tiene en cuenta el último error que se produjo al ejecutar Git por efectos secundarios. Si, por ejemplo, se produce un error mientras se genera un diff, entonces ese error no se insertará. Refrescar el buffer de estado hace que esta sección desaparezca de nuevo.

Función: magit-insert-diff-filter-header

Inserta una línea de encabezado que muestra los filtros diff efectivos.

Función: magit-insert-head-branch-header

Inserta una línea de cabecera sobre la rama actual o HEAD desanclada.

Función: magit-insert-upstream-branch-header

Inserta una línea de cabecera sobre la rama que se suele empujar a la rama actual.

Función: magit-insert-push-branch-header

Inserta una línea de cabecera sobre la rama a la que se suele empujar la rama actual.

Función: magit-insert-tags-header

Inserta una línea de cabecera sobre la etiqueta actual y/o siguiente, junto con el número de confirmaciones entre la etiqueta y HEAD.

También se pueden añadir las siguientes funciones al gancho anterior:

Función: magit-insert-repo-header

Inserta una línea de cabecera que muestra la ruta al repositorio de nivel superior.

Función: magit-insert-remote-header

Inserta una línea de cabecera sobre la remota de la rama actual.

Si no hay ninguna remota configurada para la rama actual, entonces retrocede mostrando la remota "origen", o si no existe la primera remota en orden alfabético.

Función: magit-insert-user-header

Inserta una línea de encabezado sobre el usuario actual.

Secciones del módulo de estado

El contenido de los buffers de estado se controla mediante el gancho magit-status-sections-hook (ver Secciones de estado).

Por defecto magit-insert-modules no es miembro de esa variable de gancho.

Función: magit-insert-modules

Inserta secciones de submódulos.

El gancho magit-module-sections-hook controla qué secciones del módulo se insertan, y la opción magit-module-sections-nested controla si se envuelven en una sección adicional.

Opción de Usuario: magit-module-sections-hook

Gancho ejecutado por magit-insert-modules.

Opción de Usuario: magit-module-sections-nested

Esta opción controla si magit-insert-modules envuelve las secciones insertadas en una sección adicional.

Si no es nil, sólo se inserta una sección de nivel superior. Si es nil, entonces todas las secciones listadas en magit-module-sections-hook se convierten en secciones de nivel superior.

Función: magit-insert-modules-overview

Inserta secciones para todos los submódulos. Para cada sección inserta la ruta, la rama, y la salida de git describe --tags, o, en su defecto, el hash de confirmación HEAD abreviado.

Pulse RET en la sección de un submódulo para mostrar su propio búfer de estado. Pulse RET en la sección "Módulos" para mostrar una lista de submódulos en un buffer separado. Esto muestra información adicional que no se muestra en el búfer de estado del super-repositorio.

Función: magit-insert-modules-unpulled-from-upstream

Inserta secciones para los módulos que aún no se han extraído del flujo ascendente. Estas secciones pueden ampliarse para mostrar las confirmaciones correspondientes.

Función: magit-insert-modules-unpulled-from-pushremote

Inserta secciones para los módulos que aún no se han extraído del repositorio remoto (push-remote). Estas secciones pueden ampliarse para mostrar las confirmaciones correspondientes.

Función: magit-insert-modules-unpushed-to-upstream

Inserta secciones para los módulos que aún no se han enviado al flujo ascendente. Estas secciones pueden ampliarse para mostrar las confirmaciones correspondientes.

Función: magit-insert-modules-unpushed-to-pushremote

Inserta secciones para módulos que aún no han sido empujados al push-remote. Estas secciones pueden ampliarse para mostrar las confirmaciones correspondientes.

Opciones de Estado

Opción de Usuario: magit-status-refresh-hook

El gancho se ejecuta después de que se haya actualizado un búfer de estado.

Opción de Usuario: magit-status-margin

Esta opción especifica si el margen se muestra inicialmente en las memorias intermedias del modo Magit-Status y cómo se formatea.

Este valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH).

• Si INIT es distinto de cero (si es no-nul), el margen se muestra inicialmente.
• STYLE controla el formato de la fecha del autor o del committer. Puede ser age (para mostrar la antigüedad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad hacia adelante y actualmente el valor no debe ser cambiado.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se utiliza para hacerlo.

Consulte la siguiente sección para obtener más opciones relativas a los búferes de estado.

Lista de repositorios

Comando: magit-list-repositories

Este comando muestra una lista de repositorios en un buffer separado.

La opción magit-repository-directories controla qué repositorios se muestran.

Opción de Usuario: magit-repolist-columns

Esta opción controla qué columnas muestra el comando magit-list-repositories y cómo se muestran.

Cada elemento tiene la forma (HEADER WIDTH FORMAT PROPS).

• HEADER es la cadena que se muestra en la cabecera.
• WIDTH es el ancho de la columna.
• FORMAT es una función que se llama con un argumento, la identificación del repositorio (normalmente su nombre base), y con default-directory vinculado al nivel superior de su árbol de trabajo. Debe devolver una cadena a insertar o nil. PROPS es una lista que soporta las claves :right-align, :pad-right y :sort.

La función :sort tiene una interfaz extraña descrita en el docstring de tabulated-list--get-sort. Alternativamente < y magit-repolist-version< pueden ser usadas ya que esas funciones son automáticamente reemplazadas por funciones que satisfacen la interfaz. Establezca :sort como nil para inhibir el ordenamiento; si no se especifica, la columna se puede ordenar utilizando el ordenador predeterminado.

Es posible que desee mostrar un rango de columnas numéricas usando sólo un carácter por columna y sin ningún relleno entre columnas, en cuyo caso debe usar un HEADER apropiado, establecer WIDTH a 1, y :pad-right a 9. Los números superiores a 9 se sustituyen por +.

Las siguientes funciones pueden añadirse a la opción anterior:

Función: magit-repolist-column-ident

Esta función inserta la identificación del repositorio. Normalmente es sólo su nombre base.

Función: magit-repolist-column-path

Esta función inserta la ruta absoluta del repositorio.

Función: magit-repolist-column-version

Esta función inserta una descripción de la revisión HEAD del repositorio.

Función: magit-repolist-column-branch

Esta función inserta el nombre de la rama actual.

Función: magit-repolist-column-upstream

Esta función inserta el nombre de la rama ascendente de la rama actual.

Función: magit-repolist-column-branches

Esta función inserta el número de ramas.

Función: magit-repolist-column-stashes

Esta función inserta el número de stashes¹.

Nota

¹ El stash es el guardado rápido toma el desorden del directorio de trabajo – que es, los archivos controlados por la versión modificados y cambios almacenados – y lo guarda en un saco de cambios sin terminar que puede volver a usar en cualquier momento.

Función: magit-repolist-column-flag

Esta función inserta una bandera especificada por magit-repolist-column-flag-alist.

Por defecto indica si hay cambios no comprometidos.

• N si hay al menos un fichero sin seguimiento.
• U si hay al menos un fichero sin clasificar.
• S si hay al menos un fichero en staged.

Sólo se muestra el primero de ellos que se aplica.

Función: magit-repolist-column-flags

Esta función inserta todas las banderas especificadas por magit-repolist-column-flag-alist.

Es una alternativa a la función magit-repolist-column-flag, que sólo lista la primera encontrada.

Función: magit-repolist-column-unpulled-from-upstream

Esta función inserta el número de confirmaciones "aguas arribas" (upstream) que no están en la rama actual.

Función: magit-repolist-column-unpulled-from-pushremote

Esta función inserta el número de confirmaciones en la rama push (en la rama a la que se va a empujar) pero no en la rama actual.

Función: magit-repolist-column-unpushed-to-upstream

Esta función inserta el número de confirmaciones en la rama actual pero no en su rama ascendente.

Función: magit-repolist-column-unpushed-to-pushremote

Esta función inserta el número de confirmaciones en la rama actual pero no en su rama push.

Los siguientes comandos están disponibles en los buffers de repolist:

RET (RET, magit-repolist-status)

Este comando muestra el estado del repositorio en un punto.

m (m, magit-repolist-mark)

Este comando marca el repositorio en el punto.

u (u, magit-repolist-unmark)

Este comando desmarca el repositorio en el punto.

f (f, magit-repolist-fetch)

Este comando obtiene todos los repositorios marcados. Si no se ha marcado ningún repositorio, se ofrecen todos los repositorios mostrados.

5 (5, magit-repolist-find-file-other-frame)

Este comando lee un nombre de fichero relativo (sin completar) y abre el fichero respectivo en cada repositorio marcado en un nuevo marco. Si no hay ningún repositorio marcado, ofrece hacer esto para todos los repositorios mostrados.

Registros

El buffer de estado contiene logs para las confirmaciones no empujadas y no traídas, pero eso obviamente no es suficiente. El comando de prefijo transitorio magit-log, en l, cuenta con varios comandos de sufijo, que muestran un registro específico en un buffer de registro separado.

Al igual que otros comandos de prefijo transitorio, magit-log también cuenta con varios argumentos infijos que pueden cambiarse antes de invocar uno de los comandos de sufijo. Sin embargo, en el caso del log transitorio, estos argumentos pueden tomarse de los que están actualmente en uso en el buffer de logs del repositorio actual, dependiendo del valor de magit-prefix-use-buffer-arguments (vea Argumentos transitorios y variables de buffer).

Para más información sobre los distintos argumentos, consulte la página de manual de git-log(1).

La opción ++order=VALUE se convierte en una de las opciones --author-date-order, --date-order, o --topo-order antes de pasarla a git log.

El transitorio log también incluye varios comandos reflog. Vea Reflog.

l (l, magi-log)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

ll (l l, magit-log-current)

Muestra el registro de la rama actual. Cuando HEAD está separado o con un argumento prefijo, muestra el registro de una o más revs leídas desde el minibuffer.

lh (l h, magit-log-head)

Muestra registro para HEAD.

lu (l u, magit-log-related)

Muestra el registro de la rama actual, su flujo ascendente y su destino push. Cuando el flujo ascendente es una rama local, muestra también su propio flujo ascendente. Cuando HEAD se separa, muestra el registro de esa rama, de la rama previamente extraída, de su flujo ascendente y de su objetivo push.

lo (l o, magit-log-other)

Muestra el registro de una o más revisiones leídas desde el minibuffer. El Usuario puede introducir cualquier revisión o revisiones separadas por un espacio, o incluso rangos, pero sólo las ramas, etiquetas y una representación de la confirmación en el punto están disponibles como candidatos de finalización.

lL (l L, magit log branches)

Muestra registro de todas las sucursales locales y HEAD.

lb (l b, magit-log-all-branches)

Muestra el registro de todas las sucursales locales, remotas y HEAD.

la (l a magit-log-all)

Muestra registro de todas las referencias y HEAD.

Existen dos comandos adicionales que muestran el registro del archivo o blob que se está visitando en el búfer actual, véase Comandos para búferes que visitan archivos. El comando magit-cherry también muestra un log, vea Cherries.

Actualización de Registros

El comando de prefijo transitorio magit-log-refresh, en L, puede utilizarse para cambiar los argumentos de registro utilizados en el búfer actual, sin cambiar qué registro se muestra. Esto funciona en búferes de registro dedicados, pero también en el búfer de estado.

L (L, magit-log-refresh)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Lg (L g, magit-log-refresh)

Este comando de sufijo establece los argumentos de registro local para el búfer actual.

Ls (L s, magit-log-set-default-arguments)

Este comando de sufijo establece los argumentos de registro predeterminados para los búferes del mismo tipo que el del búfer actual. Otros buffers existentes del mismo tipo no se ven afectados porque sus valores locales ya han sido inicializados.

Lw (L w, magit-log-save-default-arguments)

Este comando de sufijo establece los argumentos de registro por defecto para buffers del mismo tipo que el del buffer actual, y guarda el valor para futuras sesiones. Otros buffers existentes del mismo tipo no se ven afectados porque sus valores locales ya han sido inicializados.

LL (L L, magit-toggle-margin)

Muestra u oculta el margen.

Búfer de registro

L (L, magit-log-refresh)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Consulte Actualizar registros.

q (q, magit-log-bury-buffer)

Entierra el buffer actual o el buffer de revisión en el mismo marco. Como magit-mode-bury-buffer (que ver) pero con un argumento prefijo negativo en lugar de enterrar el búfer de revisión, siempre que se muestre en el marco actual.

Ctrl-c Ctrl-b (C-c C-b, magit-go-backward)

Retrocede en el historial de la memoria intermedia actual.

Ctrl-b Ctrl-f (C-c C-f, magit-go-forward)

Avanza en la historia del búfer actual.

Ctrl-c Ctrl-n (C-c C-n, magit-log-move-to-parent)

Mover a un padre de la confirmación actual. Por defecto, este es el primer padre, pero se puede utilizar un prefijo numérico para especificar otro padre.

j (j, magit-log-move-to-revision)

Lee una revisión y se desplaza a ella en el búfer de registro actual.

Si la referencia o revisión elegida no se muestra en el buffer de registro actual, informa al usuario de ello y no hace nada más.

Si se invoca fuera de cualquier búfer de registro, entonces muestra primero el búfer de registro del repositorio actual; creándolo si es necesario.

SPC (SPC, magit-diff-show-or-scroll-up)

Actualiza el buffer de confirmación o diff para la cosa en el punto.

Muestra la confirmación o stash en el punto en el buffer apropiado, o si ese buffer ya se está mostrando en el marco actual y contiene información sobre esa confirmación o stash, entonces desplaza el buffer hacia arriba. Si no hay confirmación o stash en el punto, entonces pide una confirmación.

DEL (DEL, magit-diff-show-or-scroll-down)

Actualiza el buffer de commit o diff para la cosa en el punto.

Muestra la confirmación o stash en el punto en el buffer apropiado, o si ese buffer ya se está mostrando en el marco actual y contiene información sobre esa confirmación o stash, entonces desplaza el buffer hacia abajo. Si no hay confirmación o stash en el punto, entonces pide una confirmación.

= (=, magit-log-toggle-commit-limit)

Cambia el número de confirmaciones al que está limitado el búfer de registro actual. Si el número de confirmaciones está limitado, elimínelo. De lo contrario, ajústelo a 256.

+ (+, magit-log-double-commit-limit)

Duplica el número de confirmaciones al que está limitado el búfer de registro actual.

- (-, magit-log-half-commit-limit)

La mitad del número de confirmaciones al que está limitado el búfer de registro actual.

Opción de Usuario: magit-log-auto-more

Inserta más entradas de registro automáticamente al pasar de la última entrada. Sólo se tiene en cuenta cuando se pasa de la última entrada con comandos magit-goto-*-section.

Opción de Usuario: magit-log-show-refname-after-summary

Si desea mostrar los nombres de referencia después de los resúmenes de confirmación. Esto es útil si usa nombres de rama muy largos.

Magit muestra las referencias en los logs de forma un poco diferente a como lo hace Git.

Las ramas locales son azules y las remotas verdes. Por supuesto, esto depende del tema usado, al igual que los colores usados para otros tipos de referencias. La rama actual tiene un recuadro a su alrededor, al igual que las ramas remotas que son la rama HEAD de su respectiva rama remota.

Si una rama local y su push-target apuntan a la misma confirmación, entonces sus nombres se combinan para preservar el espacio y hacer visible esa relación. Por ejemplo:

origin/feature
[green][blue-]

instead of

feature origin/feature
[blue-] [green-------]

Tenga en cuenta también que aunque el transient incluye el argumento --show-signature, en realidad no se usará cuando esté habilitado, porque Magit usa por defecto sólo una línea por confirmación. En su lugar, la confirmación se colorea para indicar la validez del objeto de confirmación firmado, usando las caras denominadas magit-signature-* (vea which).

Para una descripción de magit-log-margin, véase Log Margin.

Margen de Registro

En los buffers que muestran uno o más logs, es posible mostrar información adicional sobre cada confirmación en el margen. Las opciones usadas para configurar el margen se denominan magit-INFIX-margin, donde INFIX es lo mismo que en el respectivo modo principal magit-INFIX-mode. En los búferes de registro normales sería magit-log-margin.

Opción de Usuario: magit-log-margin

Esta opción especifica si el margen se muestra inicialmente en los buffers del modo Magit-Log y cómo se formatea.

El valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH).

• Si INIT no es nulo, entonces se muestra el margen inicialmente.
• STYLE controla el formato de la fecha del autor o del committer. Puede ser age (para mostrar la edad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad futura y actualmente el valor no debe cambiarse.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se utiliza para hacerlo.

Puede cambiar el STYLE y el AUTHOR-WIDTH de todas las opciones de magit-INFIX-margin a los mismos valores personalizando magit-log-margin antes de cargar magit. Si lo hace, los valores respectivos de las demás opciones serán por defecto los que haya establecido para esa variable. Del mismo modo, si establece INIT en magit-log-margin a nil, entonces se usará en el valor por defecto de todas las demás opciones. Pero si lo fija en t, es decir, si refuerza el valor por defecto de esa opción, no se aplicará a las demás opciones.

Opción de Usuario: magit-log-margin-show-committer-date

Esta opción especifica si se muestra la fecha del autor en el margen. Esta opción sólo controla si se muestra la fecha del autor en lugar de la fecha del autor. Si se muestra alguna fecha en el margen y si se muestra el margen en absoluto se controla mediante otras opciones.

L (L, magit-margin-settings)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo, cada uno de los cuales cambia la apariencia del margen de alguna manera.

En algunos buffers que soportan el margen, L está en cambio ligado a magit-log-refresh, pero ese transitorio presenta los mismos comandos, y luego algunos otros comandos no relacionados.

LL (L L, magit-toggle-margin)

Este comando muestra u oculta el margen.

Ll (L l, magit-cycle-margin-style)

Este comando cicla el estilo utilizado para el margen.

Ld (L d, magit-toggle-margin-details)

Este comando muestra u oculta detalles en el margen.

Seleccionar desde el registro

Cuando el Usuario tiene que seleccionar una confirmación reciente que es accesible desde HEAD, usar el completado regular sería inconveniente (porque la mayoría de los humanos no pueden recordar hashes o "HEAD~5", al menos no sin una doble comprobación). En su lugar, se usa un búfer de registro para seleccionar la confirmación, lo que tiene la ventaja de que las confirmaciones se presentan en orden y con el mensaje de confirmación.

Estos registros de selección se usan cuando se selecciona el comienzo de un rebase y cuando se selecciona la confirmación en la que se va a aplastar.

Además de las combinaciones de teclas disponibles en todas las memorias intermedias de registro, las siguientes combinaciones de teclas adicionales están disponibles en las memorias intermedias de registro de selección:

Ctrl-c Ctrl-c (C-c C-c, magit-log-select-pick)

Selecciona la confirmación en el punto y actúa sobre ella. Llama a magit-log-select-pick-function con la confirmación seleccionada como argumento.

Ctrl-c Ctrl-k (C-c C-k, magit-log-select-quit)

Abortar seleccionando una confirmación, no actuar sobre ninguna confirmación.

Opción de Usuario: magit-log-select-margin

Esta opción especifica si el margen se muestra inicialmente en los buffers del modo Magit-Log-Select y cómo se formatea.

El valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH).

• Si INIT no es nulo, entonces se muestra el margen inicialmente.
• STYLE controla el formato de la fecha del autor o del confirmante. Puede ser age (para mostrar la edad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad futura y actualmente el valor no debe cambiarse.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se utiliza para hacerlo.

Reflog

Consulte también la página de manual de git-reflog(1).

Estos comandos reflog están disponibles desde log transient. Ver Registros.

lr (l r, magit-reflog-current)

Muestra el reflog de la rama actual.

lO (l O, magit-reflog-other)

Muestra el reflog de una rama u otra ref.

lH (l H, magit-reflog-head)

Muestra el registro HEAD.

Opción de Usuario: magit-reflog-margin

Esta opción especifica si el margen se muestra inicialmente en las memorias intermedias del modo Magit-Reflog y cómo se formatea.

El valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH)

• Si INIT no es nulo, entonces se muestra el margen inicialmente.
• STYLE controla el formato de la fecha del autor o del confirmador. Puede ser age (para mostrar la edad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad futura y actualmente el valor no debe cambiarse.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se utiliza para hacerlo.

Cherries

Cherry-pick es mover trabajo de una rama a otra entresacandolo.

Los cherry-pick son confirmaciones que no se han aplicado al flujo ascendente (todavía), y normalmente se visualizan mediante un registro. Cada confirmación lleva el prefijo - si tiene un equivalente en el flujo ascendente y + si no lo tiene, es decir, si es un entresacado.

El comando magit-cherry muestra cherry para una única rama, pero el buffer de referencias (vea Buffer de referencias) puede mostrar cherries para múltiples "upstreams" a la vez.

Véase también la página de manual de git-reflog(1).

Y (Y, magit-cherry)

Muestra las confirmaciones que están en una rama determinada pero que no se han fusionado en la rama ascendente.

Opción de Usuario: magit-cherry-margin

Esta opción especifica si el margen se muestra inicialmente en los buffers del modo Magit-Cherry y cómo se formatea.

El valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH)

• Si INIT no es nulo, entonces el margen se muestra inicialmente.
• STYLE controla el formato de la fecha del autor o del confirmador. Puede ser age (para mostrar la edad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad futura y actualmente el valor no debe cambiarse.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se utiliza para hacerlo.

Difusión

El buffer de estado contiene diffs para las confirmaciones preparadas o no (staged y unstaged), pero eso obviamente no es suficiente. El comando de prefijo transitorio magit-diff, en d, incluye varios comandos de sufijo, que muestran un diff específico en un buffer de diff separado.

Al igual que otros comandos de prefijo transitorio, magit-diff también cuenta con varios argumentos infijos que se pueden cambiar antes de invocar uno de los comandos de sufijo. Sin embargo, en el caso del transitorio diff, estos argumentos pueden ser tomados de los que están actualmente en uso en el buffer diff del repositorio actual, dependiendo del valor de magit-prefix-use-buffer-arguments (ver Argumentos transitorios y variables del buffer).

También consulte la página de manual de git-diff(1).

d (d, magit-diff)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

dd (d d, magit-diff-dwim)

Mostrar cambios para la cosa en punto.

dr (d r, magit-diff-range)

Muestra las diferencias entre dos confirmaciones.

RANGE debe ser un rango (A..B o A...B) pero también puede ser una única confirmación. Si se omite un lado del rango, entonces por defecto es HEAD. Si sólo se indica una confirmación, se muestran los cambios en el árbol de trabajo relativos a esa confirmación.

Si la región está activa, se utilizan las revisiones de la primera y última línea de la región. Con un argumento prefijo, en lugar de diferenciar las revisiones, elija una revisión para ver los cambios a lo largo de ella, empezando en el ancestro común de ambas revisiones (es decir, use un rango "...").

dw (d w, magit-diff-working-tree)

Muestra los cambios entre el árbol de trabajo actual y la confirmación HEAD. Con un argumento prefijo muestra los cambios entre el árbol de trabajo y una confirmación leída desde el minibuffer.

ds (d s, magit-diff-staged)

Muestra los cambios entre el índice y la confirmación HEAD. Con un argumento prefijo muestra los cambios entre el índice y una confirmación leída desde el minibuffer.

du (d u, magit-diff-unstaged)

Muestra los cambios entre el árbol de trabajo y el índice.

dp (d p, magit-diff-paths)

Muestra los cambios entre dos archivos cualesquiera del disco.

Todos los comandos sufijo anteriores actualizan el buffer diff del repositorio. El transitorio diff también presenta dos comandos que muestran diferencias en otro buffer:

dc (d c, magit-show-commit)

Muestra la confirmación en el punto. Si no hay confirmación en el punto o con un argumento prefijo, pide una confirmación.

dt (d t, magit-stash-show)

Muestra todos los diffs de un stash (de un archivo escondido) en un buffer.

Existen dos comandos adicionales que muestran el diff para el archivo o blob que está siendo visitado en el buffer actual, ver Comandos para Buffers que Visitan Archivos.

Refrescar diffs

El comando prefijo transitorio magit-diff-refresh, en D, puede usarse para cambiar los argumentos diff usados en el buffer actual, sin cambiar qué diff se muestra. Esto funciona en buffers diff dedicados, pero también en el buffer de estado.

(Hay una excepción; los argumentos diff no pueden cambiarse en buffers creados por magit-merge-preview porque el comando Git subyacente no soporta estos argumentos).

D (D, magit-diff-refresh)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Dg (D g, magit-diff-refresh)

Este comando sufijo establece los argumentos diff locales para el búfer actual.

Ds (D s, magit-diff-set-default-arguments)

Este comando sufijo establece los argumentos diff por defecto para buffers del mismo tipo que el del buffer actual. Otros buffers existentes del mismo tipo no se ven afectados porque sus valores locales ya han sido inicializados.

Dw (D w, magit-diff-save-default-arguments)

Este comando sufijo establece los argumentos diff por defecto para buffers del mismo tipo que el del buffer actual, y guarda el valor para futuras sesiones. Otros buffers existentes del mismo tipo no se ven afectados porque sus valores locales ya han sido inicializados.

Dt (D t, magit-diff-toggle-refine-hunk)

Este comando activa o desactiva el refinamiento de trozos.

Dr (D r, magit-diff-switch-range-type)

Este comando convierte el tipo de rango diff de "revA..revB" a "revB...revA", o viceversa.

Df (D f, magit-diff-flip-revs)

Este comando intercambia las revisiones en el rango diff de "revA..revB" a "revB..revA", o viceversa.

DF (D F, magit-diff-toggle-file-filter)

Este comando activa la restricción de ficheros de los diffs en el buffer actual, permitiéndole cambiar rápidamente entre ver todos los cambios de la confirmación y el subconjunto restringido. Como caso especial, cuando este comando se ejecuta desde un buffer de registro, activa la restricción de ficheros en el buffer de revisiones del repositorio, lo que es útil cuando visualiza una revisión desde un buffer de registro que está restringida a un fichero o ficheros.

Además del transitorio anterior, que permite cambiar cualquiera de los argumentos admitidos, también existen algunos comandos que cambian sólo un argumento concreto.

- (-, magit-diff-less-context)

Este comando disminuye el contexto para la diferencia entre los trozos (diff hunks) por CUENTA líneas.

+ (+, magit-diff-more-context)

Este comando aumenta el contexto para diff hunks en CUENTAS líneas.

0 (0, magit-diff-default-context)

Este comando restablece el contexto para los diff hunks a la altura por defecto.

Los siguientes comandos cambian rápidamente el diff que se está mostrando sin tener que usar uno de los diff transitorios.

Ctrl-c Ctrl-d (C-c C-d, magit-diff-while-committing)

Al confirmar, este comando muestra los cambios que están a punto de confirmarse. Al modificar, si se vuelve a invocar el comando, se muestra sólo los cambios nuevos o todos los cambios que se van a confirmar.

Esta vinculación está disponible tanto en el búfer diff como en el búfer de mensajes de confirmación.

Ctrl-c Ctrl-b (C-c C-b, magit-go-backward)

Este comando retrocede en el historial del búfer actual.

Ctrl-c Ctrl-f (C-c C-f, magit-go-forward)

Este comando avanza en el historial del búfer actual.

Comandos disponibles en los diffs

Algunos comandos sólo están disponibles si el punto está dentro de un diff.

magit-diff-visit-file y las órdenes relacionadas visitan la versión apropiada del fichero del que trata el diff en el punto. Del mismo modo, magit-diff-visit-worktree-file y las órdenes relacionadas visitan la versión del árbol de trabajo del archivo del que trata el diff en el punto. Consulte Visitar archivos y blobs desde un diff para obtener más información y las combinaciones de teclas.

Ctrl-c Ctrl-t (C-c C-t, magit-diff-trace-definition)

Este comando muestra un registro de la definición en el punto.

Opción de Usuario: magit-log-trace-definition-function

La función especificada por esta opción es usada por magit-log-trace-definition para determinar la función en el punto. Para los modos principales que tienen necesidades especiales, puede establecer el valor local utilizando el gancho del modo.

Ctrl-c Ctrl-e (C-c C-e, magit-diff-edit-hunk-commit)

Desde un trozo (hunk), este comando edita la confirmación respectiva y visita el archivo.

Primero visita el archivo que está siendo modificado por el trozo en la ubicación correcta usando magit-diff-visit-file. Esto en realidad visita un blob. Cuando el punto está en una cabecera diff, no dentro de un trozo individual, entonces este visita el trozo del que trata el primer trozo.

Entonces invoca magit-edit-line-commit, que usa un rebase interactivo para hacer editable la confirmación, o si eso no es posible porque la confirmación no es accesible desde HEAD comprobando ese commit directamente. Esto también hace que se visite el archivo del árbol de trabajo real.

Ni el blob ni el buffer del fichero son eliminados al finalizar el rebase. Si esto no es deseable, entonces puede ser mejor usar magit-rebase-edit-commit en lugar de este comando.

j (j, magit-jump-to-diffstat-or-diff)

Este comando salta al diffstat o diff. Cuando el punto está en un archivo dentro de la sección diffstat, entonces salta a la sección diff respectiva. De lo contrario, salta a la sección diffstat o a un hijo de ésta.

Los dos comandos siguientes no son específicos del modo Magit-Diff (ni del búfer Magit), pero merece la pena señalar que también están disponibles aquí.

SPC (SCP, scroll-up)

Este comando desplaza el texto hacia arriba.

DEL (DEL, scroll-down)

Este comando desplaza el texto hacia abajo.

Opciones Diff

Opción de Usuario: magit-diff-refine-hunk

Si mostrar o no diferencias de granularidad de palabras dentro de los diff de los trozos.

• nil No mostrar nunca diferencias finas.
• t Mostrar diferencias finas sólo para el grupo de diferencias actual.
• all Mostrar diferencias finas para todos los diff hunks mostrados.

Opción de Usuario: magit-diff-refine-ignore-whitespace

Si se deben ignorar los cambios de espacios en blanco en las diferencias de granularidad de palabras.

Opción de Usuario: magit-diff-adjust-tab-width

Define si se ajusta el ancho de las pestañas en los diffs.

Determinar el ancho correcto puede ser costoso si requiere abrir archivos grandes y/o muchos, por lo que los anchos se almacenan en caché en la variable magit-diff--tab-width-cache. Establézcala a nil para invalidar la caché.

• nil: nunca ajusta el ancho de tabulación. Usa el valor de 'tab-width del propio buffer Magit.
• t: si el búfer correspondiente que visita el archivo existe, entonces usa el valor de tab-width de ese búfer. Hacer esto no es costoso, así que este valor se usa incluso si existe una entrada de caché correspondiente.
• always: si no existe tal búfer, entonces visita temporalmente el archivo para determinar el valor.
• NUMBER: como alway, pero no visita archivos mayores que NUMBER bytes.

Opción de Usuario: magit-diff-paint-whitespace

Especifica dónde resaltar los errores de espacio en blanco.

Véase magit-diff-highlight-trailing, magit-diff-highlight-indentation. El símbolo t significa en todos los diffs, status significa sólo en el buffer de estado, y nil significa en ningún sitio.

• nil: no resalta nunca los errores de espacio en blanco.
• t: resalta los errores de espacio en blanco en todas partes.
• uncommitted: sólo resalta los errores de espacio en blanco en los diffs que muestran cambios no comprometidos. Por compatibilidad con versiones anteriores, status se trata como un sinónimo.

Opción de Usuario: magit-diff-paint-whitespace-lines

Especifica en qué tipo de líneas resaltar los errores de espacio en blanco.

• t: resalta sólo las líneas añadidas.
• both: resalta las líneas añadidas y las eliminadas.
• all: resalta las líneas añadidas, eliminadas y contextuales.

Opción de Usuario: magit-diff-highlight-trailing

Si se resaltan los espacios en blanco al final de una línea en los diffs. Sólo se usa cuando magit-diff-paint-whitespace es distinto de nil.

Opción de Usuario: magit-diff-highlight-indentation

Esta opción controla si se resalta la sangría en caso de que se haya usado el estilo de sangría "incorrecto". La sangría sólo se resalta si magit-diff-paint-whitespace también es no nil.

El valor es una lista de la forma ((REGEXP . INDENT)...). La ruta al repositorio actual se compara con cada elemento en orden inverso. Por lo tanto, si un REGEXP coincide, no se buscarán los elementos anteriores.

Si el INDENT usado es tab, resalta la sangría con tabuladores. Si INDENT es un número entero, resalta la sangría con al menos ese número de espacios. En caso contrario, no se resalta ninguna de las dos.

Opción de Usuario: magit-diff-hide-trailing-cr-characters

Si se ocultan los caracteres ^M al final de una línea en los diffs.

Opción de Usuario: magit-diff-highlight-hunk-region-functions

Esta opción especifica las funciones usdas para resaltar la región interna del trozo.

magit-diff-highlight-hunk-region-dim-outside superpone el exterior de la selección interna del trozo con una cara que hace que las líneas añadidas y eliminadas tengan el mismo color de fondo que las líneas de contexto. Esta función no debe eliminarse del valor de esta opción.

magit-diff-highlight-hunk-region-using-overlays y magit-diff-highlight-hunk-region-using-underline enfatizan la región colocando líneas horizontales delimitadoras antes y después de ella. Ambas funciones tienen fallos que no pueden solucionarse debido a las limitaciones del motor de visualización de Emacs. Para más información, véase https://github.com/magit/magit/issues/2758.

En lugar de, o además de, usar líneas horizontales delimitadoras, para enfatizar los límites, puede querer enfatizar el texto mismo, usando magit-diff-highlight-hunk-region-using-face.

En los marcos de terminal no es posible dibujar líneas como hacen normalmente las variantes de superposición y subrayado, por lo que se recurre a la función face.

Opción de Usuario: magit-diff-unmarked-lines-keep-foreground

Esta opción controla si las líneas añadidas y eliminadas fuera de la región interna de la concavidad sólo pierden su color de fondo distintivo o también el color de primer plano. Si el exterior de la región se atenúa o no depende de magit-diff-highlight-hunk-region-functions.

Opción de Usuario: magit-diff-extra-stat-arguments

Esta opción especifica argumentos adicionales que se usarán junto con --stat.

El valor es una lista de cero o más argumentos o una función que no recibe argumentos y devuelve dicha lista. Se permiten los siguientes argumentos --stat-width, --stat-name-width, --stat-graph-width y --compact-summary. Consulte también la página de manual de git-diff(1).

Búfer de Revisión

Opción de Usuario: magit-revision-insert-related-refs

Define si se muestran ramas relacionadas en los buffers de revisión.

• nil: no muestra ninguna rama relacionada.
• t: muestra las ramas locales relacionadas.
• all: muestra las ramas locales y remotas relacionadas.
• mixed: muestra todas las ramas contenedoras y las ramas locales fusionadas.

Opción de Usuario: magit-revision-show-gravatars

Define si se muestran imágenes de gravatar en los buffers de revisión.

Si nil, no inserta ninguna imagen gravatar. Si t, inserta ambas imágenes. Si es author o committer, inserta sólo la imagen respectiva.

Si ha personalizado la opción magit-revision-headers-format y desea insertar las imágenes, puede que también tenga que especificar dónde hacerlo. En ese caso el valor tiene que ser una con-celda de dos expresiones regulares. El auto especifica dónde insertar la imagen del autor. La mitad superior de la imagen se inserta justo después del texto coincidente, la mitad inferior en la línea siguiente de la misma columna. La cdr especifica dónde insertar la imagen del autor, según corresponda. Tanto el car como el cdr pueden ser nulos".

Opción de Usuario: magit-revision-use-hash-sections

Especifica si se convierten los hashes del mensaje de confirmación en secciones.

Si no es nulo, los hashes del mensaje de confirmación se convierten en secciones de confirmación. Hay que elegir entre rendimiento y fiabilidad:

• slow: llama a git por cada palabra para estar absolutamente seguro.
• quick: omite palabras de menos de siete caracteres.
• quicker: omite además las palabras que no contienen un número.
• quickest: usa todas las palabras que tengan al menos siete caracteres y que contengan al menos un número y una letra.

Si es nil, no se convierte ningún hash en secciones, pero se puede visitar el commit (la confirmación) en el punto usando "RET".

Las diferencias mostradas en el búfer de revisión pueden restringirse automáticamente a un subconjunto de los ficheros cambiados. Si el búfer de revisión se muestra desde un búfer de registro, el búfer de revisión compartirá la misma restricción de archivos que ese búfer de registro (véase también el comando magit-diff-toggle-file-filter).

Opción de Usuario: magit-revision-filter-files-on-follow

Define si se mostrará una confirmación desde un búfer de registro respetando el filtro de archivos del registro cuando los argumentos del registro incluyan --follow.

Cuando esta opción es nil, se muestra una confirmación desde un registro ignorando el filtro de archivos del registro si los argumentos del registro incluyen --follow. De esta forma se evita mostrar un diff vacío en los buffers de revisión para confirmaciones anteriores a un evento de renombrado. En tales casos, el argumento --patch del transitorio de registro puede usarse para mostrar los diffs restringidos por fichero en línea.

Establezca esta opción a no nil para mantener la restricción de ficheros del registro incluso si --follow está presente en los argumentos del registro.

Si el búfer de revisión no se muestra desde un búfer de registro, la restricción del archivo se determina de la forma habitual (véase Argumentos transitorios y variables de búfer).

Ediff

Esta sección describe cómo introducir Ediff desde los buffers Magit. Para obtener información sobre cómo usar el propio Ediff, consulte (ediff)Top.

e (e, magit-ediff-dwim)

Compara, prepara (stage) o resuelve usando Ediff.

Este comando intenta adivinar qué fichero y qué confirmación o rango quiere el Usuario comparar, preparar o resolver usando Ediff. Puede que sólo sea capaz de adivinar el fichero o el rango/commit, en cuyo caso se pregunta al Usuario por el otro. Puede que no siempre acierte, en cuyo caso el comando magit-ediff-* apropiado tiene que ser usado explícitamente. Si no puede leer la mente del Usuario en absoluto, entonces pregunta por un comando a ejecutar.

E (E, magit-ediff)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

Er (E r, magit-ediff-compare)

Compara dos revisiones de un fichero usando Ediff.

Si la región está activa, utiliza las revisiones de la primera y última línea de la región. Con un argumento prefijo, en lugar de diferenciar las revisiones, elija una revisión para ver los cambios a lo largo de ella, comenzando en el ancestro común de ambas revisiones (es decir, use un rango "...").

Em (E m, magit-ediff-resolve-rest)

Este comando le permite resolver conflictos pendientes en el fichero en el punto usando Ediff. Si no hay ningún fichero en el punto o si no tiene ningún cambio sin fusionar, este comando solicita un fichero.

Siempre que el valor de merge.conflicttyle sea diff3, puede ver la revisión base de la fusión del fichero usando / en el buffer de control de Ediff.

Los buffers A, B y Ancestor se construyen a partir de los marcadores de conflicto en el archivo árbol de trabajo (fichero worktree). Debido a que Usted y/o Git pueden haber resuelto ya algunos conflictos, esto significa que estos buffers pueden no contener las versiones actuales de los respectivos blobs.

Em (E m, magit-ediff-resolve-all)

Este comando le permite resolver todos los conflictos del fichero en el punto usando Ediff. Si no hay ningún fichero en el punto o si no tiene ningún cambio sin fusionar, este comando le solicita uno.

Siempre que el valor de merge.conflicttyle sea , puede ver la revisión base de la fusión del fichero usando / en el buffer de control de Ediff.

Primero se aparta el fichero en el árbol de trabajo, añadiéndole el sufijo ‘.ORIG’, para poder volver más tarde a esa versión. Después se reconstruye a partir de los dos lados del conflicto y de la base de fusión, si está disponible.

Estaría bien que el fichero worktree (el árbol de trabajo) se usara tal cual, pero Ediff no lo soporta. Esto significa que todos los conflictos, que Git ya ha resuelto, son restaurados. Por otro lado Ediff también intenta resolver conflictos, y en muchos casos Ediff y Git deberían producir resultados similares.

Sin embargo, si ya ha resuelto algunos conflictos manualmente, entonces esos cambios se descartan (aunque puede recuperarlos del archivo de copia de seguridad). En tales casos magit-ediff-resolve-rest podría ser más adecuado.

La ventaja que tiene este comando sobre magit-ediff-resolve-rest es que los buffers A, B y Ancestor corresponden a blobs de los respectivas confirmaciones, permitiéndote inspeccionar un lado en contexto y usar comandos Magit en estos buffers para hacerlo. Los comandos Blame y Log son particularmente útiles aquí.

Et (E t, magit-git-mergetool)

Este comando no usa Ediff. Aunque sirve para el mismo propósito que ‘magit-ediff-resolve-rest’, usa ‘git mergetool --gui’ para resolver conflictos.

Con un argumento de prefijo actúa como un comando de prefijo transitorio, permitiendo al Usuario seleccionar la herramienta para confirmar una fusión (mergetool) y cambiar algunos parámetros.

Es (E s, magit-ediff-stage)

Coloca o saca del área de preparación (staged, unstaged) a los cambios en un archivo mediante Ediff, por defecto, cambios en el archivo en el punto.

Eu (E u)

Muestra los cambios no incluídos en el área de peparación (unstaged) de un archivo mediante Ediff.

Ei (E i)

Muestra los cambios que se han incluído en el área de preparación (staged chanes) de un archivo mediante Ediff.

Ew (E w, magit-ediff-show-working-tree)

Muestra los cambios en un archivo entre HEAD y el árbol de trabajo usando Ediff.

Ec (E c, magit-ediff-show-commit)

Muestra los cambios de un archivo introducidos por una confirmación mediante Ediff.

Ez (E z, magit-ediff-show-stash)

Muestra los cambios que no se han cofirmado de un archivo que se ha ocultado (stashing) usando Ediff.

Opción de Usuario: magit-ediff-dwim-resolve-function

Esta opción controla qué función usa magit-ediff-dwim para resolver conflictos. Una de las siguientes: magit-ediff-resolve-rest, magit-ediff-resolve-all o magit-git-mergetool; las cuales se discuten arriba.

Opción de Usuario: magit-ediff-dwim-show-on-hunks

Esta opción controla a qué comando llama magit-ediff-dwim cuando el punto está en trozos (hunks) no confirmados. Cuando es nil, siempre ejecuta magit-ediff-stage. En caso contrario, usa magit-ediff-show-staged y magit-ediff-show-unstaged para mostrar los cambios agregados o no al área de preparación (staged y unstaged), respectivamente.

Opción de Usuario: magit-ediff-show-stash-with-index

Esta opción controla si magit-ediff-show-stash incluye un búfer que contenga el estado del archivo en el índice en el momento en que se creó el stash. Esto permite saber qué cambios en el stash se realizaron por etapas.

Opción de Usuario: magit-ediff-quit-hook

Este gancho (hook) se ejecuta después de salir de una sesión Ediff que se creó usando un comando Magit. Las funciones del hook se ejecutan dentro del buffer de control de Ediff, y no deberían cambiar el buffer actual.

Es similar a ediff-quit-hook pero tiene en cuenta las necesidades de Magit. El ediff-quit-hook regular es ignorado por las sesiones Ediff que fueron creadas usando un comando Magit.

Búfer de Referencias

y (y, magit-show-refs)

Este comando lista las ramas y etiquetas en un búfer dedicado.

Sin embargo, si este comando se invoca de nuevo desde este búfer o si se invoca con un argumento de prefijo, entonces actúa como un comando de prefijo transitorio, que vincula los siguientes comandos de sufijo y algunos argumentos de infijo.

Todos los siguientes comandos de sufijo listan exactamente las mismas ramas y etiquetas. La única diferencia es la característica opcional que puede activarse cambiando el valor de magit-refs-show-commit-count (ver más abajo). Estos comandos especifican una rama o confirmación diferente con la que se comparan todas las demás referencias.

yy (y y, magit-show-refs-head)

Este comando lista las ramas y etiquetas en un buffer dedicado. Cada referencia se compara con HEAD.

yc (y c)

Este comando lista las ramas y etiquetas en un buffer dedicado. Cada referencia se compara con la rama actual o HEAD si está separada.

yo (y o, magit-show-refs-other)

Este comando lista las ramas y etiquetas en un buffer dedicado. Cada referencia se compara con una rama leída por el Usuario.

yr (y r, magit-refs-set-show-commit-count)

Este comando cambia para qué refs se muestra el recuento de confirmaciones.

Opción de Usuario: magit-refs-show-commit-count

Muestra o no los recuentos de confirmaciones en los buffers del modo Magit-Refs.

• all: muestra los recuentos de ramas y etiquetas.
• branch: muestra los recuentos sólo de las ramas.
• nil: no muestra nunca los recuentos.

El valor por defecto es nulo porque cualquier otra cosa puede resultar muy costosa.

Opción de Usuario: magit-refs-pad-commit-counts

Si se rellenan todos los recuentos de confirmaciones en todos los lados en los buffers del modo Magit-Refs.

Si es nulo (nil), algunos recuentos de confirmaciones se muestran justo al lado de una de las ramas que aparecen junto al recuento, sin ningún espacio intermedio. Esto puede quedar mal si las caras de los nombres de las ramas se parecen demasiado a magit-dimmed.

Si esto no es nil, entonces se colocan espacios a ambos lados de todos los recuentos de confirmaciones.

Opción de Usuario: magit-refs-show-remote-prefix

Muestra o no el prefijo de la remota en las listas de ramas remotas.

Muestra el prefijo es redundante porque el nombre de la remota ya se muestra en el encabezado que precede a la lista de sus ramas.

Opción de Usuario: magit-refs-primary-column-width

Anchura de la columna primaria en los buffers ‘magit-refs-mode’. La columna primaria es la columna que contiene el nombre de la rama de la que trata la fila actual.

Si es un número entero, la columna tendrá ese ancho. Si no, tiene que ser una constante de celda de dos enteros. El primero especifica la anchura mínima, el segundo la anchura máxima. En ese caso, la anchura real se determina utilizando la longitud de los nombres de las ramas locales mostradas. (Las ramas remotas y las etiquetas no se tienen en cuenta al calcular la anchura óptima).

Opción de Usuario: magit-refs-focus-column-width

Anchura de la columna de enfoque en buffers ‘magit-refs-mode’.

La columna de enfoque es la primera columna, que marca una rama (normalmente la rama actual) como la rama enfocada usando * o @. Para cada otra referencia, esta columna muestra opcionalmente cuántas confirmaciones están por delante de la rama enfocada y <, o si no está por delante entonces las confirmaciones detrás de las que está y >, o si no está detrás de ninguna, un =.

Esta columna también puede mostrar sólo * o @ para la rama enfocada, en cuyo caso esta opción se ignora. Use Lv (L v) para cambiar la verbosidad de esta columna.

Opción de Usuario: magit-refs-margin

Esta opción especifica si el margen se muestra inicialmente en las memorias intermedias del modo Magit-Refs y cómo se formatea.

Este valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH).

• Si INIT no es nulo, entonces el margen se muestra inicialmente.
• STYLE controla el formato de la fecha del autor o del confirmador (commiter). Puede ser age (para mostrar la edad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad futura y actualmente el valor no debe cambiarse.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se usa para hacerlo.

Opción de Usuario: magit-refs-margin-for-tags

Esta opción especifica si se muestra información sobre las etiquetas en el margen y está desactivada por defecto porque es lenta si hay muchas etiquetas.

Las siguientes variables controlan cómo se muestran las referencias individuales. Si cambia una de estas variables (especialmente la parte "%c"), debería cambiar también las otras para mantener las cosas alineadas. Se soportan las siguientes secuencias %:

• %a Número de confirmaciones (commits) que esta referencia tiene sobre aquella con la que comparamos.
• %b Número de confirmaciones que la referencia con la que comparamos tiene sobre ésta.
• %c Número de commits que esta ref tiene sobre aquella con la que comparamos. Para la referencia con la que se comparan todas las demás referencias es "@", si es la rama actual, o "#" en caso contrario.
• %C Para la referencia con la que se comparan todas las demás referencias es "@", si es la rama actual, o "#" en caso contrario. Para todas las demás refs " ".
• %h Hash del tip de esta ref.
• %m Resumen de la confirmación (commit) del tip de esta ref.
• %n Nombre de esta ref.
• %u Upstream de esta rama local.
• %U Corriente arriba (upstream) e información adicional de esta rama local vs. información adicional corriente arriba.

Opción de Usuario: magit-refs-filter-alist

El objetivo de esta opción es no mostrar determinadas referencias en función de su nombre. Si no desea mostrar ninguna referencia de un tipo determinado, debe eliminar la función correspondiente del gancho magit-refs-sections.

Esta lista controla qué etiquetas y ramas no se muestran en los buffers del modo magit-refs. Si es nil, se mostrarán todas las referencias (sujeto a magit-refs-sections-hook).

Todas las claves se prueban en orden hasta que una coincide. Entonces se usa su valor y se ignoran los elementos subsiguientes. Si el valor no es nulo, se muestra la referencia; de lo contrario, no. Si ningún elemento coincide, se muestra la referencia.

Una clave puede ser una expresión regular que debe coincidir con el nombre de la referencia o una función que toma el nombre de la referencia como único argumento y devuelve un booleano. Una rama remota como "origin/master" se muestra como "master", pero para esta comparación se usa la primera.

RET (RET, magit-visit-ref)

Este comando visita la referencia o revisión en el punto en otro buffer. Si no hay revisión en el punto o con un argumento prefijo, entonces solicita una.

Esta orden se comporta igual que magit-show-commit como se ha descrito anteriormente, excepto si el punto está en una referencia en un búfer magit-refs-mode, en cuyo caso el comportamiento puede ser diferente, pero sólo si ha personalizado la opción magit-visit-ref-behavior.

Opción de Usuario: magit-visit-ref-behavior

Esta opción controla cómo se comporta magit-visit-ref en los buffers del modo magit-refs.

Por defecto, magit-visit-ref se comporta como magit-show-commit, en todos los buffers, incluyendo los buffers magit-refs-mode. Cuando el tipo de la sección en el punto es commit (confirmación), "RET" está vinculado a magit-show-commit, y cuando el tipo es rama o etiqueta, entonces está vinculado a magit-visit-ref.

"RET" es una de las claves más esenciales de Magit y al menos por defecto debería comportarse de forma consistente en todo Magit, especialmente porque los Usuarios aprenden rápidamente que hace algo muy inofensivo; muestra más información sobre la cosa en el punto en otro buffer.

Sin embargo, "RET" solía comportarse de forma diferente en los buffers del modo magit-refs, haciendo cosas sorprendentes, algunas de las cuales no pueden describirse realmente como "visita esta cosa". Si ya se ha acostumbrado a este comportamiento, puede restaurarlo añadiendo uno o más de los siguientes símbolos al valor de esta opción. Pero tenga en cuenta que al hacerlo no sólo introduce incoherencias, sino que también pierde algo de funcionalidad y puede que tenga que recurrir a Alt-x magit-show-commit (M-x magit-show-commit) para recuperarla.

magit-visit-ref busca estos símbolos en el orden en que se describen aquí. Si la presencia de un símbolo se aplica a la situación actual, los símbolos que siguen no afectan al resultado.

focus-on-ref

Con un argumento de prefijo actualiza el buffer para mostrar los recuentos de confirmaciones y listas de confirmaciones de cherries relativas a la referencia en el punto en lugar de relativas al buffer actual o HEAD.

En lugar de añadir este símbolo, considere pulsar "Ctrl-u (C-u) y/o RET (RET)".

create-branch

Si el punto está en una rama remota, entonces crea una nueva rama local con el mismo nombre, usa la rama remota como su upstream, y luego comprueba la rama local.

En lugar de añadir este símbolo, considera pulsar "bc RETRET (b c RET RET)", como haría en otros buffers.

checkout-any

Comprueba la referencia en el punto. Si esa referencia es una etiqueta o una rama remota, entonces esto resulta en un HEAD independiente.

En lugar de añadir este símbolo, considera pulsar "bb RET (b b RET)", como se haría en otros buffers.

checkout-branch

Comprueba la rama local en el punto

En lugar de añadir este símbolo, considere pulsar "bb RET (b b RET)", como haría en otros buffers.

Secciones de Referencias

Bisecting

B (B, magit-bisect)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

Cuando la bisección no está en curso, el transitorio presenta los siguientes comandos de sufijo.

BB (B B, magit-bisect-start)

Inicia una sesión de bisección.

Bisectar un fallo significa encontrar la confirmación que lo introdujo. Este comando inicia una sesión de bisección pidiendo dos confirmaciones: una buena y una mala, ambas conocidas. Si está bisectando un cambio que no es una regresión, puede seleccionar términos alternativos que sean conceptualmente más adecuados que "malo" y "bueno", pero los argumentos infijos para hacerlo están desactivados por defecto.

Bs (B s, magit-bisect-run)

Bisecta automáticamente ejecutando comandos después de cada paso.

Si la bisección está en curso, el transitorio presenta en su lugar los siguientes comandos de sufijo.

Bb (B b, magit-bisect-bad)

Marca la confirmación actual como mala. Úselo después de haber comprobado que la confirmación contiene el error en cuestión.

Bg (B g, magit-bisect-good)

Marca la confirmación actual como buena. Úselo después de haber comprobado que la confirmación no contiene el error en cuestión.

Bm (B m, magit-bisect-mark)

Marca la confirmación actual con uno de los términos bisect. Este comando proporciona una alternativa a magit-bisect-bad y magit-bisect-good y es útil cuando se usan términos distintos de "bad" y "good". Este sufijo está desactivado por defecto.

Bk (B k, magit-bisect-skip)

Omite la confirmación actual. Úselo si por alguna razón la confirmación actual no es una buena confirmación para probar. Este comando permite a Git elegir uno diferente.

Br (B r, magit-bisect-reset)

Después de bisectar, limpia el estado de bisección y vuelve a la HEAD original.

Por defecto, el búfer de estado muestra información sobre la sesión bisect en curso.

Opción de Usuario. magit-bisect-show-graph

Esta opción controla si se muestra un gráfico para el registro de confirmaciones que aún tienen que ser bisectadas.

Visitar archivos y blobs

Magit proporciona varios comandos que visitan un archivo o blob (la versión de un archivo que se almacena en una determinada confirmación). En realidad proporciona varios grupos de tales comandos y las diversas variantes dentro de cada grupo.

Véase Comandos para buffers que visitan archivos.

Comandos de Visita de Propósito General

Estos comandos pueden usarse en cualquier lugar para abrir cualquier blob. Actualmente no hay teclas vinculadas a estos comandos por defecto, pero es probable que eso cambie.

Comando: magit-find-file

Este comando lee un nombre de archivo y una revisión del Usuario y visita la nota correspondiente en un búfer. El búfer se muestra en la ventana seleccionada.

Comando: magit-find-file-other-window

Este comando lee un nombre de archivo y una revisión del Usuario y visita el blob respectivo en un buffer. El búfer se muestra en otra ventana.

Comando: magit-find-file-other-frame

Este comando lee un nombre de archivo y una revisión del Usuario y visita la nota correspondiente en un búfer. El búfer se muestra en otro marco.

Visitar archivos y Blobs desde un Diff

Estos comandos sólo pueden usarse cuando el punto está dentro de un diff.

RET (RET, magit-diff-visit-file)

Este comando visita la versión apropiada del fichero del que trata el diff en cuestión.

Este comando visita la versión del árbol de trabajo del fichero apropiado. La posición del punto dentro del diff determina qué fichero se visita. La versión visitada depende de los cambios sobre los que trata el diff.

1. Si el diff muestra cambios no confirmados (es decir, cambios que se han preparados o no), entonces visita el fichero en el árbol de trabajo (es decir, el mismo fichero "real" que visitaría find-file. En todos los demás casos, visita un "blob" (es decir, la versión de un archivo almacenada en alguna confirmación).
2. Si el punto está en una línea eliminada, entonces visita el "blob" para el primer padre de la confirmación que eliminó esa línea, es decir, la última confirmación en la que todavía existe esa línea.
3. Si el punto está en una línea añadida o contextual, entonces visita la nota que añade esa línea, o si el diff muestra más de una confirmación, entonces visita la nota de la última de esas confirmaciones.

En el búfer de visita de ficheros, este comando va a la línea que corresponde a la línea en la que se encuentra ese punto en el diff.

La memoria intermedia se muestra en la ventana seleccionada. Con un argumento de prefijo, la memoria intermedia se muestra en otra ventana.

Opción de Usuario: magit-diff-visit-previous-blob

Esta opción controla si magit-diff-visit-file puede visitar la nota anterior. Cuando es t (por defecto) y el punto está en una línea eliminada en un diff para un cambio confirmado, entonces magit-diff-visit-file visita la nota de la última revisión que todavía tenía esa línea.

Actualmente esto sólo está soportado para cambios confirmados, para cambios preparados o no, magit-diff-visit-file siempre visita el fichero en el árbol de trabajo.

Ctrl-RET (C-return, magit-diff-visit-file-worktree)

Este comando visita la versión del árbol de trabajo del fichero correspondiente. La ubicación del punto dentro del diff determina qué archivo se está visitando. A diferencia de magit-diff-visit-file, siempre visita el archivo "real" en el árbol de trabajo, es decir, la "versión actual" de dicho archivo.

En el búfer de visita de archivos este comando va a la línea que corresponde a la línea en la que se encuentra ese punto en el diff. Las líneas que se han añadido o eliminado en el árbol de trabajo, el índice y otros commits intermedios se tienen en cuenta automáticamente.

El buffer se muestra en la ventana seleccionada. Con un argumento prefijo, la memoria intermedia se muestra en otra ventana.

Existen variantes de los dos comandos anteriores que visitan el archivo en otra ventana o en otro marco. Si prefiere este comportamiento, puede cambiar las combinaciones de teclas anteriores, pero tenga en cuenta que los comandos anteriores también usan otra ventana cuando se invocan con un argumento de prefijo.

Comando: magit-diff-visit-file-other-window.
Comando: magit-diff-visit-file-other-frame.
Comando: magit-diff-visit-worktree-file-other-window.
Comando: magit-diff-visit-worktree-file-other-frame.

Blaming

Para iniciar blaming, invoque el comando de prefijo transitorio magit-file-dispatch. Cuando se usan los atajos de teclado por defecto, esto se puede hacer pulsando Ctrl-c M-g (C-c M-g). Si se usan las combinaciones recomendadas, este comando se ejecuta pulsando Ctrl-c f (C-c f). Véase Combinaciones globales.

Los comandos de sufijo de blaming pueden invocarse directamente desde el transitorio de envío de archivos. Sin embargo, si desea establecer un argumento infijo, primero debe introducir el subprefijo de blaming.

Ctrl-c fB (C-c f B, magit-blame)
Ctrl-c fb (C-c f b, magit-blame-addition)
Ctrl-c fBb (C-c f B b)
Ctrl-c fr (C-c f r, magit-blame-removal)
Ctrl-c fBr (C-c f B r)
Ctrl-c ff (C-c f f, magit-blame-reverse)
Ctrl-c fBf (C-c f B f)
Ctrl-c fe (C-c f e, magit-blame-echo)
Ctrl-c fBe (C-c f B e)
Ctrl-c fq (C-c f q, magit-blame-quit)
Ctrl-c fBq (C-c f B q)

Ctrl-c Alt-g B (C-c M-g B, magit-blame)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Ctrl-c Alt-g b (C-c M-g b, magit-blame-addition)
Ctrl-c Alt-g Bb (C-c M-g B b)

Este comando aumenta cada línea o trozo de líneas en el búfer que visita el fichero o blob actual con información sobre qué commit tocó esas líneas por última vez.

Si el buffer visita una revisión de ese fichero, entonces se considera la historia hasta esa revisión. En caso contrario, se considera el historial completo del fichero, incluyendo los cambios no confirmados.

Si el modo Magit-Blame ya está activado en el buffer actual, la culpabilización se hace recursivamente, visitando REVISION:ARCHIVO (usando magit-find-file), donde REVISION es un padre de la revisión que añadió la línea o trozo de líneas actual.

Ctrl-c Alt-g r (C-c M-g r, magit-blame-removal)
Ctrl-c Alt-g Br (C-c M-g B r)

Este comando incrementa cada línea o trozo de líneas en la memoria intermedia que visita el blob actual con información sobre la revisión que lo elimina. No se puede usar en las memorias intermedias que visitan archivos.

Al igual que magit-blame-addition, este comando puede usarse de forma recursiva.

Ctrl-c Alt-g f (C-c M-g f, magit-blame-reverse)
Ctrl-c Alt-g B (C-c M-g B f)

Este comando aumenta cada línea o trozo de líneas en el búfer actual que visita archivos o blobs con información sobre la última revisión en la que todavía existía una línea.

Al igual que magit-blame-addition, este comando puede usarse de forma recursiv.

Ctrl-c Alt-g e (C-c M-g e, magit-blame-echo)
Ctrl-c Alt-g Be (C-c M-g B e)

Este comando es como magit-blame-addition excepto que no activa el modo de sólo lectura y que inicialmente usa el estilo de visualización especificado por la opción magit-blame-echo-style.

Las siguientes combinaciones de teclas están disponibles cuando el modo Magit-Blame está activado y el modo Sólo lectura no está activado. Estos comandos también están disponibles en otras memorias intermedias; aquí sólo se describe el comportamiento que es relevante en las memorias intermedias que visitan archivos a los que se está haciendo blaming.

Ctrl-c Alt-g q (C-c M-g q, magit-blame-quit)
Ctrl-c Alt-g Bq (C-c M-g B q)

Este comando desactiva el modo Magit-Blame. Si el buffer fue creado durante una blame recursivo, entonces también mata el buffer.

RET (RET, magit-show-commit)

Este comando muestra la última confirmación que tocó la línea en el punto.

SPC (SPC, magit-diff-show-or-scroll-up)

Este comando actualiza la memoria intermedia de confirmaciones (commit buffer).

Esto muestra la última confirmación que tocó la línea en el punto en el búfer apropiado, o si ese búfer ya se está mostrando en el marco actual y si ese búfer contiene información sobre esa confirmación, entonces el búfer se desplaza hacia arriba en su lugar.

DEL (DEL, magit-diff-show-or-scroll-down)

Este comando actualiza la memoria intermedia de confirmaciones.

Esto muestra la última confirmación que tocó la línea en el punto del búfer apropiado, o si ese búfer ya se está mostrando en el fotograma actual y si ese búfer contiene información sobre esa confirmación, entonces el búfer se desplaza hacia abajo en su lugar.

Las siguientes combinaciones de teclas están disponibles cuando están activados tanto el modo Magit-Blame como el modo Sólo lectura.

b (b, magit-blame)

Vea más arriba.

n (n, magit-blame-next-chunk)

Este comando pasa al siguiente trozo (next chunk).

N (N, magit-blame-next-chunk-same-commit)

Este comando pasa al siguiente trozo de la misma confirmación.

p (p, magit-blame-previous-chunk)

Este comando se desplaza al trozo anterior.

P (P, magit-blame-previous-chunk-same-commit)

Este comando se desplaza al fragmento anterior de la misma confirmación.

q (q, magit-blame-quit)

Este comando desactiva el modo Magit-Blame. Si el buffer fue creado durante un blame recursivo, entonces también mata el buffer.

Alt-w (M-w, magit-blame-copy-hash)

Este comando guarda el hash de la confirmación del trozo actual en el anillo de destrucción (kill ring).

Cuando la región está activa, el comando guarda el contenido de la región en lugar del hash, como haría kill-ring-save.

c (c, magit-blame-cycle-style)

Este comando cambia la forma en que se visualiza la información de autoría en el bbúfer actual mediante un ciclo a través de los estilos especificados usando la opción magit-blame-styles.

El blaming también se controla mediante las siguientes opciones.

Opción de Usuario: magit-blame-styles

Esta opción define una lista de estilos usados para visualizar la información de autoría. Por ahora, consulte su doc-string para obtener más información.

Opción de Usuario: magit-blame-echo-style

Esta opción especifica el estilo de visualización de blame usado por el comando magit-blame-echo. Debe ser un símbolo que se use como identificador de uno de los estilos definidos en magit-blame-styles.

Opción de Usuario: magit-blame-read-only

Esta opción controla si un búfer blaming también hace que sea temporalmente de sólo lectura.

Opción de Usuario: magit-blame-disable-modes

Esta opción enumera los modos secundarios incompatibles que deben desactivarse temporalmente cuando un búfer contiene información de autoría. Se vuelven a habilitar cuando el búfer deja de mostrar información de autoría.

Opción de Usuario: magit-blame-goto-chunk-hook

Este gancho se ejecuta cuando se mueve entre trozos.

Manipulación

Creando Repositorios

I (I, magit-init)

Este comando inicializa un repositorio y luego muestra el búfer de estado del nuevo repositorio.

Si el directorio está debajo de un repositorio existente, entonces el Usuario tiene que confirmar que debe crearse uno nuevo dentro. Si el directorio es la raíz del repositorio existente, tiene que confirmar que debe ser reinicializado.

Clonando un Repositorio

Para clonar un repositorio remoto o local use C, que está ligado al comando magit-clone. Este comando puede actuar como un comando prefijo transitorio, que enlaza varios argumentos infijos y comandos sufijos, o puede invocar a git clone directamente, dependiendo de si se usa un argumento prefijo y del valor de magit-clone-always-transient.

Opción de Usuario: magit-clone-always-transient

Esta opción controla si el comando magit-clone actúa siempre como un comando de prefijo transitorio, independientemente de si se usa o no un argumento de prefijo. Si es t, esa orden siempre actúa como prefijo transitorio. Si es nil, tiene que usarse un argumento de prefijo para que actúe como transitorio.

C (C, magit-clone)

Este comando actúa como un comando de prefijo transitorio como se describió anteriormente o hace lo mismo que transient-clone-regular como se describe a continuación.

Si actúa como prefijo transitorio, vincula los siguientes comandos sufijos y varios argumentos infijos.

CC (C C, magit-clone-regular)

Este comando crea un clon regular de un repositorio existente. El repositorio y el directorio de destino se leen desde el Usuario.

Cs (C s, magit-clone-shallow)

Este comando crea un clon superficial de un repositorio existente. El repositorio y el directorio de destino se leen del Usuario. Por defecto, la profundidad del historial clonado es una única confirmación, pero con un argumento prefijo la profundidad se lee del Usuario.

C> (C >, magit-clone-sparse)

Este comando crea un clon de un repositorio existente e inicia una comprobación dispersa, evitando la comprobación del árbol de trabajo completo. Para añadir más directorios, use el transitorio magit-sparse-checkout (vea Sparse checkouts).

Cb (C b, magit-clone-bare)

Este comando crea un clon desnudo de un repositorio existente. El repositorio y el directorio de destino se leen desde el Usuario.

Cm (C m, magit-clone-mirror)

Este comando crea una réplica de un repositorio existente. El repositorio y el directorio de destino se leen desde el Usuario.

Los siguientes sufijos están desactivados por defecto. Consulte Activación y desactivación (transitoria) de sufijos para saber cómo activarlos.

Cd (C d, magit-clone-shallow-since)

Este comando crea un clon superficial de un repositorio existente. Sólo se clonan las confirmaciones posteriores a una fecha, que se lee del Usuario. El repositorio y el directorio de destino también se leen desde el Usuario.

Ce (C e, magit-clone-shallow-exclude)

Este comando crea un clon superficial de un repositorio existente. Esto lee una rama o etiqueta del Usuario. Las confirmaciones accesibles desde ahí no se clonan. El repositorio y el directorio de destino también se leen del Usuario.

Opción de Usuario: magit-clone-set-remote-head

Esta opción controla si al clonar se crea la referencia refs/remotes/<remote>/HEAD en el clon. El valor por defecto es borrar la referencia después de ejecutar git clone, que insiste en crearla. Esto se debe a que no se ha encontrado que la referencia sea particularmente útil, ya que no se actualiza automáticamente cuando cambia el HEAD del remoto. Establecer esta opción a t preserva el comportamiento por defecto de Git de crear la referencia.

Opción de Usuario: magit-clone-set-remote.pushDefault

Esta opción controla si el valor de la variable Git remote.pushDefault se establece después de la clonación.

• Si es t, siempre se establece sin preguntar.
• Si es ask, se pregunta a los Usuarios cada vez que clonan un repositorio.
• Si es nil, nunca se establece.

Opción de Usuario: magit-clone-default-directory

Esta opción controla el nombre de directorio por defecto usado al leer el destino de una operación de clonación.

• Si es nil (por defecto), se utiliza el valor del directorio por defecto.
• Si es un directorio, se utiliza éste.
• Si es una función, se llama a ésta con la url remota como único argumento y se utiliza el valor devuelto.

Opción de Usuario: magit-clone-name-alist

Esta opción mapea expresiones regulares, que coinciden con nombres de repositorios, a urls de repositorios, haciendo posible que los Usuarios introduzcan nombres cortos en lugar de urls al clonar repositorios.

Cada elemento tiene la forma (REGEXP HOSTNAME USUARIO). Cuando el Usuario introduce un nombre cuando un comando de clonación pide un nombre o url, entonces se busca en esta lista. Se utiliza el primer elemento cuyo REGEXP coincida.

El formato especificado por la opción magit-clone-url-format se usa para convertir el nombre en una url, usando HOSTNAME y el nombre del repositorio. Si el nombre proporcionado contiene una barra, entonces se usa. En caso contrario, si el nombre omite el propietario del repositorio, se usará el Usuario por defecto especificado en la entrada correspondiente.

Si USER contiene un punto, entonces se trata como una variable Git y su valor se usa como nombre de usuario. En caso contrario, se usa como nombre de usuario.

Opción de Usuario: magit-clone-url-format

El formato especificado por esta opción se usa cuando se convierten nombres de repositorios en urls. %h es el nombre del host y %n es el nombre del repositorio, incluyendo el nombre del propietario. El valor puede ser una cadena (que representa un único formato estático) o una lista con elementos (HOSTNAME . FORMAT) que asignan nombres de host a formatos. Cuando se usa una lista, la clave t representa el formato por defecto.

Ejemplo de cadena de formato simple:

(setq magit-clone-url-format
      "git@%h:%n.git")
	

Ejemplo de cadenas de formato by-hostname:

(setq magit-clone-url-format
      '(("git.example.com" . "git@%h:~%n")
        (nil . "git@%h:%n.git")))
	

Opción de Usuraio: magit-post-clone-hook

El gancho se ejecuta después de que el proceso Git haya finalizado con éxito la clonación del repositorio. Cuando el gancho es llamado, default-directory es let-bound al directorio donde el repositorio ha sido clonado.

Cambios Preparados y No Preparados (staged/unstaged)

Al igual que Git, Magit puede, por supuesto, preparar y retirar archivos completos del área de preparación. A diferencia de Git, Magit también permite a los Usuarios sacar del área de preparación pedazos de archivos individuales e incluso trozos de una parte de un archivo. Para poner partes de archivos individuales y partes de archivos en el área de preparación usando Git directamente, hay que usar la interfaz muy modal y bastante torpe de una sesión git add --interactive.

Con Magit, por otro lado, se pueden sacar del área de preparación partes individuales (hunks) simplemente moviendo el punto en la sección respectiva dentro de un diff mostrado en el búfer de estado o en un búfer de diff separado y tecleando s o u. Para operar sólo en partes de un hunk, marque los cambios que deben ser sacados del área de preparación usando la región y luego pulse la misma tecla que se usaría para sacarlos de esta área. Para procesar varios ficheros o partes a la vez, use una región que empiece dentro del encabezado de la sección y termine dentro del encabezado de una sección hermana del mismo tipo.

Además de la inclusión y desvinculación del área de preparación, Magit también proporciona otras "variantes de aplicación" que también pueden operar sobre uno o varios archivos, un o varios trozo a la vez y sobre partes de un trozo. Estas variantes de aplicación se describen en la siguiente sección.

También puede usar Ediff para incluír o desvincular del área de preparación. Véase Ediffing.

s (s, magit-stage)

Añade el cambio en el punto al área de preparación.

Con un argumento de prefijo y un fichero (o ficheros) sin seguimiento en el punto, pone en escena el fichero pero no su contenido. De este modo, sólo se puede poner en escena un subconjunto de los cambios del nuevo archivo.

S (S, magit-stage-modified)

Añade al área de preparación (stage) todos los cambios de los archivos modificados en el árbol de trabajo y todo el contenido nuevo de los archivos rastreados. Elimina del índice los archivos rastreados que ya no existen en el árbol de trabajo. Con un argumento de prefijo, también se preparan los archivos no seguidos previamente (pero no ignorados).

u (u, magit-unstage)

Elimina el cambio en el punto del área de preparación.

Sólo pueden sacarse del área de preparación (unstaged) los cambios que previamente se han puesto ahí. Pero por defecto este comando realiza una acción algo similar a retiralos aún cuando no estuviesen incluídos en dicha área, cuando se llama sobre un cambio confirmado: anula el cambio en el índice pero no en el árbol de trabajo.

U (U, magit-unstage-all)

Retira todos los cambios del área de preparación (staging area).

Opción de Usuario: magit-unstage-committed

Esta opción controla si magit-unstage "deshace" los cambios confirmados invirtiéndolos en el índice pero no en el árbol de trabajo. La alternativa es generar un error.

Alt-x magit-reverse-in-index (M-x magit-reverse-in-index)

Este comando invierte el cambio confirmado en un punto del índice pero no del árbol de trabajo. Por defecto no hay ninguna tecla asociada directamente a este comando, pero se ejecuta indirectamente cuando se pulsa u (magit-unstage) en un cambio confirmado.

Esto permite extraer un cambio de HEAD, dejándolo en el árbol de trabajo, para que pueda ser confirmado más tarde usando una confirmación separada. Un flujo de trabajo típico sería:

1. Opcionalmente, asegúrese de que no hay cambios no confirmados.
2. Visite la confirmación HEAD y navegue hasta el cambio que no debería haber sido incluido en esa confirmación.
3. Escriba u (magit-unstage) para revertirlo en el índice. Esto asume que magit-unstage-committed-changes no es nulo.
4. Escriba ce para extender HEAD con los cambios incluídos en el área de preparación, sumándolos los que ya estaban incluídos anteriormente.
5. Opcionalmente, incluya en el área de preparación los cambios restantes usando s o S y, a continuación, escriba cc para crear una nueva confirmación.

Alt-x magit-reset-index (M-x magit-reset-index)

Restablece el índice a alguna confirmación. Dicha confirmación se lee del Usuario y por defecto es la confirmación en el punto, si no la hay, por defecto es HEAD.

Vea Incluír en área de preparación a partir de búferes que están visitando archivos.

Área de preparación (staging area) desde archivo visitado en el buffer

La inclusión o exclusión detallada al/desde (el) área de preparación debe hacerse desde el estado o desde un búfer diff, pero también es posible eliminar todos los cambios realizados en el archivo visitado en el búfer actual desde dentro de ese búfer.

Alt-x magit-stage-file ( M-x magit-stage-file )

Cuando se invoca dentro de un búfer que visita un archivo, pone en el área de preparación a todos los cambios de ese archivo. En un buffer Magit, se pone en escena el archivo en cuestión, si existe. En caso contrario, solicita un fichero para ser preparado. Con un argumento de prefijo, siempre pide al Usuario un archivo, incluso en un archivo que está siendo visitado por un buffer o cuando hay una sección de archivos en el punto.

Alt-x magit-unstage-file ( M-x magit-unstage-file )

Cuando se invoca desde un buffer que visita un archivo, deshace todos los cambios en ese archivo. En un buffer Magit, saca del área de preparación al archivo en el punto si lo hay. En caso contrario, solicita un fichero para ser desafectado de dicha área. Con un argumento de prefijo, siempre pide al Usuario un archivo, incluso en un buffer que visita archivos o cuando hay una sección de archivo en el punto.

Aplicación

Magit proporciona varias formas de aplicar un parche: preparado (stage), sin preparar (unstage), descartar (discard), revertir (reverse) y una forma llamada aplicación regular (regular apply). Al menos cuando se opera sobre un trozo, todas ellas se implementan usando git apply, que es por lo que se llaman variantes de aplicación.

• Preparación (stage). Aplica en el índice un cambio que haya en el árbol de trabajo . El cambio también permanece en el árbol de trabajo.
• Sacar del área de preparación (unstage). Elimina una modificación en el índice. La modificación permanece en el árbol de trabajo.
• Descartar. A un cambio preparado, lo elimina del árbol de trabajo y del índice. A un cambio no preparado, lo elimina sólo del árbol de trabajo.
• Revertir (reverse). Anula un cambio en el árbol de trabajo. Se pueden anular tanto los cambios confirmados como los cambios por etapas. Los cambios no confirmados no se pueden anular. En su lugar, deséchelos.
• Aplicar. Aplica un cambio al árbol de trabajo. Tanto los cambios confirmados como los cambios por etapas pueden ser aplicados. Los cambios no preparados no pueden aplicarse, puesto que ya se han aplicado.

En la sección anterior se han descrito los comandos para incluir en el área de preparación o sacar de ella. A continuación se describen los comandos que implementan las variantes de aplicación restantes.

a (a, magit-apply)

Aplica el cambio en el punto al árbol de trabajo.

Con un argumento de prefijo se vuelve a una fusión de 3 vías. Al hacerlo, el cambio se aplica también al índice.

k (k, magit-discard)

Elimina en el punto el cambio que haya en el árbol de trabajo.

En un trozo o fichero con conflictos sin resolver, pregunta qué lado mantener (descartando el otro). Si el punto está dentro del texto de un lado, entonces conserva ese lado sin preguntar.

v (v, magit-reverse)

Revierte el cambio del árbol de trabajo en un punto.

Con un argumento de prefijo, retrocede a una fusión de 3 vías. Al hacerlo, el cambio se aplica también al índice.

Con un argumento prefijo, todas las variantes de apply intentan una fusión a tres vías cuando es apropiado (es decir, cuando git apply se usa internamente).

Confirmando

Cuando el Usuario inicia una confirmación (un commit), Magit llama a git commit sin ningún argumento, por lo que Git tiene que obtenerlo del Usuario. Ello crea el archivo .git/COMMIT_EDITMSG y luego abre ese archivo en un editor. Magit se encarga de que ese editor sea Emacsclient. Una vez que el Usuario termina la sesión de edición, el Emacsclient sale y Git crea el commit usando el contenido del archivo como mensaje.

Iniciando una Confirmación

c (c, magit-commit)

Cuando el Usuario inicia una confirmación, Magit llama a git commit sin ningún argumento, por lo que Git tiene que obtenerlo del Usuario. Crea el archivo .git/COMMIT_EDITMSG y luego abre ese archivo en un editor. Magit se encarga de que ese editor sea Emacsclient. Una vez que el Usuario termina la sesión de edición, se cierra Emacsclient y Git crea la confirmación usando el contenido del archivo como mensaje.

cc (c c, magit-commit-create)

Crea una nueva confirmación en HEAD. Con un argumento de prefijo, en su lugar modifica la confirmación en HEAD.

ca (c a, magit-commit-amend)

Modifica el último commit.

m e (c e, magit-commit-extended)

Modifica la última confirmación, sin editar el mensaje. Con un argumento prefijo se mantiene la fecha del autor de la confirmación (commiter), en caso contrario se cambia. La opción magit-commit-extend-override-date puede usarse para invertir el significado del argumento prefijo.

De forma no interactiva, respeta el argumento opcional OVERRIDE-DATE e ignora la opción.

cw (c w, magit-commit-reword)

Reordena la última confirmación, ignorando los cambios por etapas. Con un argumento prefijo se mantiene la fecha del committer, en caso contrario se cambia. La opción magit-commit-reword-override-date puede usarse para invertir el significado del argumento prefijo.

Respeta de forma no interactiva el argumento opcional OVERRIDE-DATE e ignora la opción.

cf (c f, magit-commit-fixup)

Crea una confirmación de corrección.

Con un argumento prefijo, es necesario notificar el objetivo de la confirmación. De lo contrario, la confirmación en el punto puede usarse sin aclaración dependiendo del valor de la opción magit-commit-squash-confirm.

cF (c F, magit-commit-instant-fixup)

Crea una confirmación de corrección y vuelve a reorganizar (rebase) al instante.

cs (c s, magit-commit-squash)

Crea una confirmación de un aplastamiento (squash commit), sin editar el mensaje squash.

Con un argumento prefijo, se debe aclarar el objetivo de esta confirmación. De lo contrario, la confirmación en el punto puede usarse sin aclarar nada dependiendo del valor de la opción magit-commit-squash-confirm.

cS (c S, magit-commit-instant-squash)

Crea una confirmación de aplastamiento (squash commit) y reorganiza (rebase) al instante.

cA (c A, magit-commit-augment)

Crea una confirmación de aplastamiento (un squash commit), editando el mensaje squash.

Con un argumento prefijo, la confirmación (el commit) de destino tiene que ser reafirmada. De lo contrario, el commit en el punto puede usarse sin confirmación dependiendo del valor de la opción magit-commit-squash-confirm.

Opción de Usuario: magit-commit-ask-to-stage

Se pregunta si incluír en el área de preparación (staged area) a todos los cambios aún no incorporados en dicha área (unstaged) cuando se confirma sin haber incluído nada.

Opción de Usuario: magit-commit-show-diff

Define si el diff relevante se muestra automáticamente al confirmar.

Opción de Usuario: magit-commit-extend-override-date

Define si el uso de magit-commit-extend cambia la fecha de confirmación.

Opción de Usuario: magit-commit-reword-override-date

Define si el uso de magit-commit-reword cambia la fecha de confirmación.

Opción de Usuario: magit-commit-squash-confirm

Define si la confirmación a la que se dirige squash y fixup tiene que ser confirmada. Si no es nulo, la confirmación en el punto (si existe) se usa por defecto. En caso contrario, debe confirmarse. Esta opción sólo afecta a magit-commit-squash y magit-commit-fixup. Las variantes "instantáneas" siempre requieren confirmación porque es más difícil de recuperar si se comete un error durante su uso.

Opción de Usuario: magit-post-commit-hook

Gancho que se ejecuta después de crear una confirmación sin que el Usuario edite un mensaje.

Este gancho es ejecutado por magit-refresh si esta orden es miembro de magit-post-commit-hook-commands. Esto sólo incluye comandos llamados magit-commit-* que no requieren que el Usuario edite el mensaje de confirmación en un buffer.

Véase también git-commit-post-finish-hook.

Opción de Usuario: magit-commit-diff-inhibit-same-window

Define si inhibir el uso de la misma ventana cuando se muestra diff al confirmar.

Cuando se escribe una confirmación, se muestra automáticamente un diff de los cambios a confirmar. La idea es que el diff se muestre en una ventana diferente del mismo marco y para la mayoría de los Usuarios eso simplemente funciona. En otras palabras, la mayoría de los Usuarios pueden ignorar completamente esta opción porque su valor no supone ninguna diferencia.

Sin embargo para los Usuarios que configuraron Emacs para que nunca cree una nueva ventana incluso cuando el paquete explícitamente intente hacerlo, mostrar dos nuevos buffers significa necesariamente que el primero es inmediatamente reemplazado por el segundo. En nuestro caso, el búfer de mensajes es inmediatamente reemplazado por el búfer de diferencias, lo cual es, por supuesto, altamente indeseable.

Una solución consiste en suprimir esta configuración de Usuario en este caso concreto. Los Usuarios tienen que activar explícitamente esta opción. No podemos habilitar la solución incondicionalmente porque esto causaría problemas a otros Usuarios: si el marco es demasiado pequeño o los ajustes relevantes demasiado agresivos, el buffer de diferencias (diff) acabaría mostrándose en un nuevo marco.

Vea https://github.com/magit/magit/issues/4132.

Edición de los Mensajes de Confirmación

Después de iniciar una confirmación como se describe en la sección anterior, aparecen dos nuevos búferes. Uno muestra los cambios que están a punto de ser confirmados, mientras que el otro se usa para escribir el mensaje.

Los mensajes de confirmación se editan en una sesión de edición -en segundo plano git está esperando a que el editor, en nuestro caso emacsclient- guarde el mensaje de confirmación en un archivo (en la mayoría de los casos .git/COMMIT_EDITMSG) y luego regrese. Si el editor vuelve con un estado de salida distinto de cero, entonces git no crea la confirmación. Así que los comandos más importantes son los de finalizar y abortar la confirmación.

Ctrl-c Ctrl-c (C-c C-c, with-editor-finish)

Finaliza la sesión de edición actual devolviendo el código de salida 0. A continuación, Git crea la confirmación usando el mensaje que encuentra en el archivo.

Ctrl-c Ctrl-k (C-c C-k, with-editor-cancel)

Cancela la sesión de edición actual devolviendo el código de salida 1. Git cancela la confirmación, pero deja el archivo intacto.

Además de ser utilizados por git commit, los mensajes también pueden almacenarse en un anillo que persiste hasta que se cierra Emacs. Por defecto, el mensaje se almacena al principio y al final de una sesión de edición (independientemente de si la sesión ha terminado con éxito o ha sido cancelada). A veces es útil recuperar mensajes de ese anillo.

Ctrl-c Alt-s (C-c M-s, git-commit-save-message)

Guarda el contenido del búfer actual en el anillo de mensajes de confirmación.

Alt-p (M-p, git-commit-prev-message)

Ciclo hacia atrás a través del anillo de mensajes de confirmación, después de guardar el mensaje actual en el anillo. Con un prefijo numérico ARG, retrocede ARG comentarios.

Por defecto, el diff (las diferencias) de los cambios que están a punto de ser confirmados se muestra automáticamente al invocar la confirmación. Para evitarlo, elimine magit-commit-diff de server-switch-hook.

Cuando se modifica una confirmación existente puede ser útil mostrar los cambios que están a punto de ser añadidos a esa confirmación o mostrar esos cambios junto a los que ya han sido confirmados.

Ctrl-c Ctrl-d (C-c C-d, magit-diff-while-committing)

Al confirmar, muestra los cambios que están a punto de confirmarse. Al modificar, si se vuelve a invocar el comando, se muestra sólo los cambios nuevos o todos los cambios que se van a confirmar.

Uso de la pila de revisión

Ctrl-c Ctrl-w (C-c C-w, magit-pop-revision-stack)

Este comando inserta una representación de una revisión en el buffer actual. Puede usarse dentro de buffers empleados para escribir mensajes de confirmación, pero también en otros buffers como los que se usan para editar correos electrónicos o archivos ChangeLog.

Por defecto, este comando extrae la última revisión añadida a la pila magit-revision-stack y la inserta en el búfer actual según el formato magit-pop-revision-stack-format. Las revisiones pueden colocarse en la pila usando magit-copy-section-value y magit-copy-buffer-revision.

Si la pila está vacía o con un argumento prefijo, en su lugar lee una revisión en el minibuffer. Usar el historial del minibuffer permite seleccionar un elemento que se ha extraído anteriormente o insertar una referencia o revisión arbitraria sin introducirla primero en la pila.

Cuando se lee la revisión desde el minibuffer, puede que no sea posible adivinar el repositorio correcto. Cuando se llama a este comando dentro de un repositorio (por ejemplo, mientras se redacta un mensaje de confirmación), se usa ese repositorio. En caso contrario (por ejemplo, mientras redacta un correo electrónico), se usará el repositorio registrado para el elemento superior de la pila (aunque insertemos otra revisión). Si no se llama dentro de un repositorio y con una pila vacía, o con dos argumentos prefijo, entonces lee también el repositorio en el minibuffer.

Opción de Usuario: magit-pop-revision-stack-format

Esta opción controla cómo el comando magit-pop-revision-stack inserta una revisión en el buffer actual.

Las entradas en la pila tienen el formato (HASH TOPLEVEL) y esta opción tiene el formato (POINT-FORMAT EOB-FORMAT INDEX-REGEXP), todos los cuales pueden ser nulos o una cadena (aunque uno de EOB-FORMAT o POINT-FORMAT debería ser una cadena, y si INDEX-REGEXP no es nulo, entonces los dos formatos deberían serlo también).

Primero se usa INDEX-REGEXP para encontrar la entrada previamente insertada, buscando hacia atrás desde el punto. La primera subpartida debe coincidir con el número de índice. Ese número se incrementa en uno, y se convierte en el número de índice de la entrada que se va a insertar. Si no desea numerar las revisiones insertadas, use nil para INDEX-REGEXP.

Si INDEX-REGEXP es distinto de cero, tanto POINT-FORMAT como EOB-FORMAT deben contener ‘%N\’, que se sustituye por el número determinado en el paso anterior.

Ambos formatos, si no son nulos y después de eliminar %N, se expanden usando git show --format=FORMAT ... dentro de TOPLEVEL.

La expansión de POINT-FORMAT se inserta en el punto, y la expansión de EOB-FORMAT se inserta al final del buffer (si el buffer termina con un comentario, entonces se inserta justo antes de eso).

Pseudo Cabeceras de la Confirmación

Algunos proyectos usan pseudocabeceras en los mensajes de confirmación. Magit colorea dichas cabeceras y proporciona algunos comandos para insertarlas.

Opción de Usuario: git-commit-known-pseudo-headers

Una lista de pseudocabeceras Git a destacar.

Ctrl-c Ctrl-i (C-c C-i, git-commit-insert-pseudo-header)

Inserta una pseudocabecera de mensaje de confirmación.

Ctrl-c Ctrl-a (C-c C-a, git-commit-ack)

Inserta una " cabecera " reconociendo que Ud. ya ha revisado la confirmación.

Ctrl-c Ctrl-r (C-c C-r, git-commit-review)

Inserte un cabecera reconociendo que ha revisado la confirmación.

Ctrl-c Ctrl-s (C-c C-s, git-commit-sigoff)

Inserta un encabezado para firmar la confirmación.

Ctrl-c Ctrl-t (C-c C-t, git-commit-test)

Inserta un encabezado reconociendo que ha verificado la confirmación.

Ctrl-c Ctrl-o (C-c C-o, git-commit-cc)

Inserta un encabezado mencionando a alguien que pueda estar interesado.

Ctrl-c Ctrl-p (C-c C-p, git-commit-reported)

Inserta un encabezado mencionando a la persona que informó del problema que se soluciona con la confirmación.

Ctrl-c Alt-i (C-c M-i)

Inserta un encabezado mencionando a la persona que sugirió el cambio.

Modo Confirmación y Ganchos

git-commit-mode es un modo menor que sólo se usa para establecer ciertos enlaces clave. Esto hace posible emplear un modo mayor arbitrario en los buffers usados para editar los mensajes de confirmación. Incluso es posible utilizar diferentes modos mayores en diferentes repositorios, lo cual es útil cuando diferentes proyectos imponen diferentes convenciones de mensajes de confirmación.

Opción de Usuario: git-commit-major-mode

El valor de esta opción es el modo principal utilizado para editar los mensajes de confirmación de Git.

Debido a que git-commit-mode es un modo menor, no usamos su gancho (hook) de modo para configurar el buffer, excepto para los enlaces clave. El resto de la configuración se hace en la función git-commit-setup, que entre otras cosas ejecuta el gancho git-commit-setup-hook.

Opción de Usuario: git-commit-setup-hook

Gancho que se ejecuta al final de git-commit-setup.

Las siguientes funciones son adecuadas para este gancho:

Función: git-commit-save-message

Guarda el contenido del búfer actual en el anillo de mensajes de confirmación.

Función: git-commit-setup-changelog-support

Después de llamar a esta función, las entradas de ChangeLog se tratan como párrafos.

Función: git-commit-turn-on-auto-fill

Activa el modo de autocompletado (auto-fill-mode).

Función: git-commit-turn-on-flyspell

Activa el modo Flyspell. Evita que se comprueben los comentarios y, por último, revisa que el texto actual no sea comentario.

Función: git-commit-propertize-diff

Adecuar la diferencia mostrada (el diff) dentro del búfer del mensaje de confirmación. Git inserta tales diffs en la plantilla del mensaje de confirmación cuando se usa el argumento --verbose. magit-commit por defecto no ofrece ese argumento porque el diff que se muestra en un buffer separado es más útil. Pero algunos Usuarios no están de acuerdo, y por eso existe esta función.

Función: bug-reference-mode

Referencias de errores de hipervínculo en el búfer.

Función: with-editor-usage-message

Muestra información de uso en el área de eco.

Opción de Usuario:

Gancho que se ejecuta después de que el Usuario haya terminado de escribir un mensaje de confirmación.

Este gancho sólo se ejecuta después de pulsar Ctrl-c Ctrl-c (C-c C-c) en un buffer utilizado para editar un mensaje de confirmación. Si se crea una confirmación sin que el Usuario haya escrito un mensaje en un buffer, entonces este gancho no se ejecuta.

Este gancho no se ejecuta hasta que se haya creado la nueva confirmación. Si esto le lleva a Git más de un segundo, entonces este gancho no se ejecuta. Para ciertos comandos, como magit-rebase-continue, este gancho nunca se ejecuta porque si lo hiciera se produciría una condición de carrera.

Este gancho sólo se ejecuta si magit está disponible.

Vea magit-post-commit-hook.

Convenciones para mensajes de confirmación

Git-Commit resalta ciertas violaciones de las convenciones comúnmente aceptadas en los mensajes de confirmación. Ciertas violaciones incluso hacen que Git-Commit le pida que confirme que: realmente quiere hacer eso. Esta molestia puede, por supuesto, ser desactivada, pero el resultado de hacer eso por lo general es que en lugar de algún código es ahora el humano que está revisando sus confirmaciones, el que tiene que perder algo de tiempo diciéndole que las corrija.

Opción de Usuario: git-commit-summary-max-length

La longitud máxima prevista para la línea de resumen de los mensajes de confirmación. Los caracteres que superan esta columna se colorean para indicar que se ha violado esta preferencia.

Opción de Usuario: git-commit-finish-query-functions

Lista de funciones llamadas a consulta antes de llevar a cabo la confirmación.

El búfer de mensajes de confirmación está activo mientras se llama a las funciones. Si alguna de ellas devuelve nil, entonces no se ejecuta la confirmación y no se elimina el búfer. El Usuario debe solucionar el problema e intentarlo de nuevo.

Las funciones se llaman con un argumento. Si no es nulo, indica que el Usuario usó un argumento prefijo para forzar la finalización de la sesión a pesar de los problemas. Normalmente, las funciones deberían respetar este deseo y devolver un valor no nulo.

Por defecto el único miembro es git-commit-check-style-conventions.

Opción de Usuario: git-commit-check-style-conventions

Esta función comprueba si se infringen determinadas convenciones básicas de estilo. Para cada violación pregunta a los Usuarios si desean continuar de todos modos.

Opción de Usuario: git-commit-style-conventions-checks

Esta opción controla qué convenciones intenta aplicar la función del mismo nombre. El valor es una lista de símbolos autoexplicativos que identifican ciertas convenciones; segunda línea no vacía y línea de resumen demasiado larga.

Modelo de Ramificación (Branching)

Dos ramas remotas

El flujo ascendente (upstream) de una rama local es la rama en la que las confirmaciones de esa rama local se fusionarán finalmente, por lo general algo así como origin/master. Para la rama maestra en sí, la rama upstream y la rama a la que se está empujando, suelen ser la misma rama remota. Pero para una rama de características, la rama upstream y la rama a la que se está empujando deben ser diferentes.

Las confirmaciones de las ramas de características también deberían acabar en una rama remota como origin/master u origin/maint. Por lo tanto, dicha rama debe ser usada como upstream. Pero las ramas de características no deben ser empujadas directamente a esas ramas. En su lugar, una rama de característica mi-característica es generalmente empujado a mi-bifuración/mi-característica o si Usted es un contribuyente origin/mi-característica. Una vez revisada la nueva funcionalidad, el responsable la fusiona con master. Y finalmente master (no mi-característica en sí) es empujado a origin/master.

Pero las nuevas funcionalidades rara vez son perfectas al primer intento, por lo que las ramas de funcionalidades suelen tener que revisarse, mejorarse y volverse a empujar (re-pushed) varias veces. Por lo tanto, empujar debería ser fácil de hacer, y por esa razón muchos usuarios de Git han llegado a la conclusión de que lo mejor es usar la rama remota a la que se está empujando la rama de características local como su upstream.

Pero por suerte Git ya hace tiempo que tiene soporte para un push-remote que puede configurarse de forma separada de la rama upstream, usando las variables branch.<name>.pushRemote y remote.pushDefault. Así que ya no tenemos que elegir cuál de los dos remotos debe usarse como "el remoto".

Cada uno de los comandos transitorios fetching, pulling y pushing presenta tres comandos sufijo que actúan sobre la rama actual y alguna otra rama. De estos, p está ligado a un comando que actúa sobre el push-remote, u está ligado a un comando que actúa sobre el upstream, y e está ligado a un comando que actúa sobre cualquier otra rama. El búfer de estado muestra las confirmaciones no enviadas (no pushed) y no traídas (no pulled) tanto para el push-remote como para el upstream.

Es bastante sencillo configurar estos dos remotos. Los valores de todas las variables que están relacionadas con fetching, pulling y pushing (así como algunas otras variables relacionadas con las ramas) pueden ser inspeccionadas y cambiadas usando el comando magit-branch-configure, que está disponible desde muchos comandos de prefijo transitorio que tratan con ramas. También es posible configurar el push-remote o upstream mientras se realiza el push (ver Pushing).

Comandos de Rama

El comando de prefijo transitorio de magit para ramas se usa para crear ramas y cambiar entre ellas, y para realizar cambios en las ramas existentes. No se usa para buscar, obtener (fetch), eniar (pull), fusionar (merge), llevar a cabo rebase o empujar ramas (push), es decir, este comando trata con ramas mismas, no con las confirmaciones accesibles de ellas. Esas características están disponibles en un comando transitorio separado.

b (b, magit-branch)

Este comando de prefijo transitorio une los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoca un sufijo.

Por defecto, también une y muestra los valores de algunas variables Git relacionadas con la rama y permite cambiar sus valores.

Opción de Usuario; magit-branch-direct-configure

Esta opción controla si el comando transitorio magit-branch se puede usar para cambiar directamente los valores de las variables Git. Este valor predeterminado es t (para evitar cambiar los enlaces clave). Cuando se establece en nil, ese comando transitorio no muestra variables, y en su lugar se de usar su comando sufijo transitorio magit-branch-configure para ver y cambiar las variables relacionadas con la rama.

bC (b Cmagit-branch-configure)
fC (f C)
FC (F C)
PC (P C)

Este comando de prefijo transitorio une los comandos que establecen el valor de las variables relacionadas con la rama y las muestra en un búfer temporal hasta que salga el transitorio.

Con un argumento de prefijo, este comando siempre solicita una rama.

Sin un argumento de prefijo, esto depende de si se invocó como un sufijo de magit-branch y de magit-branch-direct-configure. Si magit-branch ya muestra las variables para la rama actual, no es útil invocar otro transitorio que las muestra para la misma rama. En ese caso, este sistema solicita una rama.

Las variables se describen en Git, variables de rama.

bb (b b, magit-checkout)

Consulta una revisión leída en el minibuffer y no muestra la rama o la revisión arbitraria en el punto. Si la revisión es una rama local, entonces esa se convierte en la rama actual. Si es algo más, se separa HEAD. Checkout falla si el árbol de trabajo o el área de preparación contienen cambios.

bn (b n, magit-branch-create)

Crea una nueva rama. Se le pide al usuario una rama o una revisión arbitraria para usar como punto de partida de la nueva rama. Cuando se proporciona un nombre de rama, eso se convierte en la rama ascendente de la nueva rama. El nombre de la nueva rama también se lee en el minibuffer.

Véase también magit-branch-prefer-remote-upstream

bc (b c, magit-branch-and-checkout)

Este comando crea una nueva rama como magit-branch-create, pero luego también la verifica.

Véase también la opción magit-branch-prefer-remote-upstream

bl (b l, magit-branch-checkout)

Este comando verifica una rama local existente o nueva. Lee un nombre de rama del usuario que ofrece todas las ramas locales y un subconjunto de ramas remotas como candidatas. Las ramas remotas para las cuales existe una rama local con el mismo nombre se omiten de la lista de candidatos. El usuario también puede ingresar un nombre de rama completamente nueva.

• Si el usuario selecciona una rama local existente, se verifica.
• Si el usuario selecciona una rama remota, crea y verifica una nueva rama local con el mismo nombre, y configura la rama remota seleccionada como el destino de lo que se va a enviar.
• Si el usuario ingresa a un nuevo nombre de rama, la crea y verifica, después de leer también el punto de partida del usuario.

En los últimos dos casos también se establece el flujo ascedente (upstream). Si está configurado en el punto de partida elegido o algo más depende del valor de magit-branch-adjust-remote-upstream-alist.

bs (b s, magit-branch-spinoff)

Este comando crea y verifica una nueva rama que comienza y rastrea la rama actual. Esa rama a su vez se restablece al último confirmación que comparte con su flujo ascendente. Si la rama actual no tiene flujo ascedente o confirmaciones sin enviar, la nueva rama se crea de todos modos y la rama actual no se toca.

Esto es útil para crear una rama de características después de que el trabajo ya haya comenzado en la antigua rama (probablemente pero no necesariamente como rama "maestra").

Si la rama actual es un miembro del valor de la opción magit-branch-prefer-remote-upstream (que ver), entonces la rama actual se usará como el punto de partida como de costumbre, pero el flujo ascendente del punto de partida puede ser usado como el flujo ascendente de la nueva rama, en lugar del punto de partida en sí.

Si la opción FROM es no-nul, la rama fuente se restablece a FROM~, en lugar de la última confirmación que comparte con el flujo ascendente. Interactivamente, FROM nunca es no-nula, si la región selecciona algunas confirmaciones, entre esas confirmaciones, FROM es la menor cantidad de confirmaciones por delante de la rama fuente.

La confirmación en el otro extremo de la selección en realidad no importa, todas las confirmaciones FROM y HEAD se trasladan a la nueva rama. Si FROM no es accesible desde HEAD o es accesible desde la rama origen del flujo ascendente, entonces se plantea un error.

bS (b S, magit-branch-spinout)

Este comando se comporta como magit-branch-spinoff, excepto que no cambia la rama actual. Si hay cambios no confirmados, se comporta exactamente como magit-branch-spinoff.

bx (b x, magit-branch-reset)

Este comando restablece una rama, por defecto a la rama en el punto, a la punta de otra rama o cualquier otra confirmación.

Cuando la rama que se reinicia es la rama actual, se lleva a cabo un reinicio duro. Si hay algún cambio no confirmado, el usuario debe confirmar el reinicio porque esos cambios se perderían.

Esto es útil cuando ha comenzado a trabajar en una rama de funciones, pero se da cuenta de que todo es basura y quiere comenzar de nuevo.

Al reiniciar a otra rama y se usa un argumento de prefijo, entonces la rama objetivo se establece como el flujo ascendennte de la rama que se está restableciendo.

bk (b k, magit-branch-delete)

Elimina una o múltiples ramas. Si la región marca múltiples ramas, ofrece eliminarlas. De lo contrario, solicita que se elimine una sola rama, por defecto la rama en el punto.

De alguna manera es peligroso requerir confirmación. La opción magit-no-confirm se puede personalizar para no requerir confirmación en ciertos casos. Consulte su documento para saber por qué se requiere confirmación de forma predeterminada en ciertos casos o si un aviso es confuso.

bm (b m, magit-branch-rename)

Cambia el nombre de una rama. La rama y el nuevo nombre se leen en el minibuffer. Con el argumento de prefijo, la rama se renombra incluso si ese nombre entra en conflicto con una rama existente.

Opción de Usuario: magit-branch-read-upstream-first

Configura si al crear una rama, se leerá la rama del flujo ascendente antes que el nombre de la rama que se creará. El valor predeterminado es t, y le recomiendo que lo deje en eso.

Opción de Usuario: magit-branch-prefer-remote-upstream

Esta opción especifica si se favorecen los flujos ascendentes remotos sobre los flujos ascendentes locales al crear nuevas ramas.

Cuando se crea una nueva rama, se sugiere un nombre de rama, confirmación o, archivos (o partes de un archivo) escondidos en el punto como el punto de partida de la nueva rama, o si no hay tal revisión en el punto de la rama actual. En cualquier caso, el usuario puede elegir otro punto de partida.

Si el punto de partida elegido es una rama, entonces también se puede establecer como el flujo ascendente de la nueva rama, dependiendo del valor de la variable GIT ‘branch.autoSetupMerge’. Por defecto, esto se hace para ramas remotas, pero no para ramas locales.

Es posible que prefiera usar siempre una rama remota como flujo ascendente. Si el punto de partida elegido es (1) una rama local, (2) cuyo nombre coincide con un miembro del valor de esta opción, (3) el flujo ascendente de esa rama local es una rama remota con el mismo nombre, y (4) Esa rama remota puede ser avanzada rápidamente a la rama local, luego la rama elegida se usa como punto de partida, pero su propio flujo ascendete (upstream) se usa como upstrem de la nueva rama.

Los miembros del valor de esta opción se tratan como nombres de ramas que tienen que igualar exactamente a menos que contengan un caracter que los haga inválidos como un nombre de rama. Los caracteres recomendados para usar para desencadenar la interpretación como expresión regular son ‘*’ y ‘^’. Algunos otros caracteres de los que se puede esperar que sean inválidos, en realidad no lo son, por ejemplo, ‘.+$’ son perfectamente válidos. Más precisamente, si git check-ref-format-branch CADENA sale con un estado distinto de cero, luego trata la CADENA como un expresión regular.

Suponiendo que la rama elegida cumpla estas condiciones, acabaría con:
e.g.:

feature --upstream--> origin/master
	

en lugar de:

feature --upstream--> master --upstream--> origin/master
	

Lo que Usted elija es una cuestión de preferencia personal. Si prefiere lo primero, entonces debe añadir ramas como master, next y maint al valor de esta opción.

Opción de Usuario: magit-branch-adjust-remote-upstream-alist

El valor de esta opción es una lista de ramas que se usarán como flujo ascendente (upstream) al crear una rama remota.

Cuando se crea una rama local a partir de una rama efímera localizada en una rama remota, por ejemplo, una rama de características o de revisiones, esa rama remota no debería usarse normalmente como rama ascendente, ya que la rama push-remota ya permite acceder a ella y tener tanto la rama ascendente como la push-remota haciendo referencia a la misma rama relacionada sería un desperdicio. En su lugar, una rama como "maint" o "master" debería usarse como upstream.

Esta opción permite especificar la rama que debe usarse como ascendente al bifurcar ciertas ramas remotas. El valor es una lista de la forma ((UPSTREAM . RULE)...). Se usa el primer elemento que coincida, los siguientes se ignoran.

UPSTREAM es la rama que se usará como upstream para las ramas especificadas por RULE. Puede ser una rama local o remota.

RULE puede ser una expresión regular que busque ramas cuyo flujo ascendente sea el especificado por UPSTREAM. O puede ser una lista de las únicas ramas que no deben usar UPSTREAM; todas las demás ramas lo harán. La coincidencia se hace después de eliminar la parte remota del nombre de la rama desde la que se está creando la rama.

Si usa un conjunto finito de ramas no efímeras en todos sus repositorios, podría usar algo como:

(("origin/master" . ("master" "next" "maint")))
	

O si los nombres de todas sus ramas efímeras contienen una barra, al menos en algunos repositorios, un buen valor podría ser:

(("origin/master" . "/"))
	

Por supuesto, también se puede ajustar:

(("origin/maint" . "\\`hotfix/")
 ("origin/master" . "\\`feature/"))
	

UPSTREAM puede ser una rama local:

(("master" . ("master" "next" "maint")))
	

Como la rama principal ya no se llama casi siempre "master", debe tener en cuenta otros nombres comunes:

(("main"  . ("main" "master" "next" "maint"))
 ("master" . ("main" "master" "next" "maint")))
	

Comando: magit-branch-orphan

Este comando crea y comprueba una nueva rama huérfana con contenidos de una revisión dada.

Comando: magit-branch-or-checkout

Este comando es un híbrido entre magit-checkout y magit-branch-and-checkout y pretende sustituir al primero en magit-branch.

Primero pregunta al Usuario por una rama o revisión existente. Si la entrada del Usuario puede ser resuelta como una rama o revisión, entonces la comprueba, como haría magit-checkout.

En caso contrario, crea y comprueba una nueva rama usando la entrada como nombre. Antes de hacerlo, lee el punto de inicio de la nueva rama. Esto es similar a lo que hace magit-branch-and-checkout.

Para usar este comando en lugar de magit-checkout añada esto a su archivo init:

(transient-replace-suffix 'magit-branch 'magit-checkout
  '("b" "dwim" magit-branch-or-checkout))
	

Variables de Ramas Git

Estas variables pueden establecerse desde el comando de prefijo transitorio magit-branch-configure. Por defecto, también pueden establecerse desde magit-branch. Vea Comandos de Rama.

Variable: branch.NAME.merge

Junto con branch.NAME.remote, esta variable define la rama ascendente de la rama local denominada NAME. El valor de esta variable es la referencia completa de la rama ascendente.

Variable: branch-NAME.remote

Junto con branch.NAME.merge esta variable define la rama del flujo ascendente (upstream) de la rama local llamada NAME. El valor de esta variable es el nombre de la remota del upstream.

Variable: branch.NAME.rebase

Esta variable controla si la inserción en la rama NAME (NOMBRE) se efectúa mediante un cambio de base o mediante la fusión de la rama obtenida.

• Si es true (verdadera), la extracción se realiza por reorganización (rebasing).
• Si es false, la extracción se realiza mediante fusión (merging).
• Si no se define, se usaa el valor de pull.rebase. El valor por defecto de esta variable es false.

Variable: branch.NAME.pushRemote

Esta variable especifica la remota a la que se suele enviar la rama denominada NAME (NOMBRE). El valor tiene que ser el nombre de una rama existente.

No es posible especificar el nombre de la rama a la que se envía la rama local. El nombre de la rama remota es siempre el mismo que el de la rama local.

Si esta variable no está definida pero remote.pushDefault si está definida, se usará el valor de esta última. Por defecto, remote.pushDefault no está definida.

Variable: branch.NAME.description

Esta variable puede usarse para describir la rama denominada NAME (NOMBRE). Esa descripción se usa, por ejemplo, al convertir la rama en una serie de parches.

Las siguientes variables especifican los valores predeterminados que se usan si no se establecen las variables específicas de la rama anteriores.

Variable: pull.rebase

Esta variable especifica si la extracción se realiza por reorganización (rebase) o por fusión (merging). Puede sobrescribirse utilizando branch.NAME.rebase.

• Si es true (verdadero), la extracción se efectua reorganizando (rebasing).
• Si es false (por defecto), la extracción se lleva a cabo mediante fusión (merging).

Dado que nunca es una buena idea fusionar la rama del flujo ascendente (upstream) en una rama feature¹ o hotfix¹ y la mayoría de las ramas son ramas de este tipo, debería considerar establecer esto a true, y branch.master.rebase a false.

Importante

¹ Rama feature o hotfix son ramas paralelas sobre las que se trabaja de forma temporal.

Variable: remote.pushDefault

Esta variable especifica a qué remoto se envían normalmente las ramas locales. Se puede sobrescribir por rama usando branch.NAME.pushRemote.

Las siguientes variables se usan durante la creación de una rama y controlan si las diversas variables específicas de la rama se establecen automáticamente en este momento.

Variable: branch.autoSetupMerge

Esta variable especifica en qué circunstancias la creación de una rama NOMBRE debe dar lugar a que se establezcan las variables branch.NOMBRE.merge y branch.NOMBRE.remote según el punto de partida usado para crear la rama. Si el punto de partida no es una rama, estas variables nunca se establecen.

• Si es always (siempre), las variables se establecen independientemente de si el punto de partida es una rama local o remota.
• Si es true (verdadero), que es el valor por defecto), las variables se definen cuando el punto de partida es una rama remota, pero no cuando es una rama local.
• Si es false (falso), las variables no se fijan nunca.

Variable: branch.autoSetupRebase

Esta variable especifica si la creación de una rama NOMBRE debe dar lugar a que la variable branch.NOMBRE.rebase se establezca en verdadero.

• Si es always (siempre), la variable se establece independientemente de si el punto de partida es una rama local o remota.
• Si es local, la variable se establece cuando el punto de partida es una rama local, pero no cuando es una rama remota.
• Si es remote (remota), la variable se activa cuando el punto de partida es una rama remota, pero no cuando es una rama local.
• Cuando es never (nunca) que es el valor por defecto, la variable nunca se establece.

Tenga en cuenta que los comandos respectivos siempre cambian los valores locales del repositorio. Si desea cambiar el valor global, que se usa cuando el valor local no está definido, tiene que hacerlo en la línea de comandos, por ejemplo:

git config --global remote.autoSetupMerge always

Para más información sobre estas variables, consulte git-config(1), git-branch(1), git-checkout y Pushing.

Opción de Usuario: magit-prefer-remote-upstream

Esta opción controla si los comandos que leen una rama del Usuario y luego la establecen como rama del flujo ascendente (upstream), ofrecen una rama local o una rama remota como candidato de finalización por defecto, cuando tienen la opción.

Esto afecta a todas las órdenes que usan magit-read-upstream-branch o magit-read-starting-point, lo que incluye todas las órdenes que cambian el upstream y muchas que crean nuevas ramas.

Comandos auxiliares de rama

Estos comandos no están disponibles por defecto en la rama transitoria magit-branch.

Comando: magit-branch-shelve

Este comando archiva (shelves) una rama. Esto se hace borrando la rama, y creando una nueva referencia "refs/shelved/BRANCH-NAME" apuntando a la misma confirmación a la que apuntaba la rama. Si la rama eliminada tenía un reflog, éste se conserva como reflog¹ de la nueva referencia.

Nota

¹ Un reflog es un registro de cambios (log) que git lleva a cabo en segundo plano, en donde se apuntan las referencias de su cabecera (HEAD) y su rama en los últimos meses.

Esto es útil si desea mover una rama fuera de la vista, pero no está lista para descartarla por completo todavía.

Comando: magit-branch-unshelve

Este comando libera una rama que fue previamente almacenada usando magit-branch-shelve. Esto se hace borrando la referencia "refs/shelved/BRANCH-NAME" y creando una rama "BRANCH-NAME" apuntando a la misma confirmación (commit) a la que apuntaba la referencia borrada. Si la referencia eliminada tenía un reflog, éste se restaura como reflog de la rama.

Fusión (merging)

También puede revisar la página de manual de git-merge(1). si desea información sobre cómo resolver conflictos de fusión, consulte la siguiente sección.

m (m, magit-merge)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Cuando no hay ninguna fusión en curso, el transitorio presenta los siguientes comandos de sufijo.

mm (m m, magit-merge-plain)

Este comando fusiona otra rama o una revisión arbitraria en la rama actual. La rama o revisión a fusionar se lee en el minibuffer y por defecto es la rama en el punto.

A menos que haya conflictos o se utilice un argumento de prefijo, la confirmación de fusión resultante usa un mensaje de confirmación genérico, y el Usuario no tiene la oportunidad de inspeccionarlo o cambiarlo antes de que se cree la confirmación. Con un argumento de prefijo esto no crea realmente la confirmación, lo que hace posible inspeccionar cómo se resolvieron los conflictos y ajustar el mensaje de confirmación.

me (m e, magit-merge-editmsg)

Este comando fusiona otra rama o una revisión arbitraria en la rama actual y abre un búfer de mensajes de confirmación, para que el Usuario pueda hacer ajustes. La confirmación no se crea hasta que el Usuario termina con C-c C-c

mn (m n, magit-merge-nocommit)

Este comando fusiona otra rama o una revisión arbitraria en la rama actual, pero no crea realmente la confirmación de fusión. El Usuario puede entonces ajustar la fusión, incluso cuando la resolución automática de conflictos ha tenido éxito y/o ajustar el mensaje de confirmación.

ma (m a, magit-merge-absorb)

Este comando fusiona otra rama local en la rama actual y luego elimina la primera.

Antes de fusionar la rama fuente, primero se fuerza su push-remote, siempre que la rama remota respectiva ya exista. Esto asegura que el pull-request respectivo (si existe) no se atascará en alguna versión obsoleta de los commits que se están fusionando. Finalmente, si magit-branch-pull-request se usó para crear la rama fusionada, entonces la rama remota respectiva también se elimina.

mi (m i, magit-commit-into)

Este comando fusiona la rama actual con otra rama local y, a continuación, elimina la primera. Esta última se convierte en la nueva rama actual.

Antes de fusionar la rama fuente, primero se fuerza su push-remote, siempre que la rama remota respectiva ya exista. Esto asegura que el pull-request respectivo (si existe) no se quede atascado en alguna versión obsoleta de las confirmaciones que se están fusionando. Finalmente, si magit-branch-pull-request se usó para crear la rama fusionada, entonces la rama remota respectiva también se elimina.

ds (d s, magit-merge-squash)

Este comando aplasta los cambios introducidos por otra rama o una revisión arbitraria en la rama actual. Esto sólo aplica los cambios realizados por los commits aplastados. No se conserva ninguna información que permita crear una confirmación de fusión real. En lugar de este comando, probablemente debería usar un comando del transitorio apply.

mp (m p, magit-merge-preview)

Este comando muestra una vista previa de la fusión de otra rama o una revisión arbitraria en la rama actual.

Tenga en cuenta que los comandos, que normalmente cambian la forma en que se muestra un diff, no funcionan en los buffers creados por este comando, porque el comando Git subyacente no soporta argumentos diff.

Cuando una fusión está en curso, el transitorio presenta en su lugar los siguientes comandos de sufijo.

mm (m m, magit-merge)

Después de que el Usuario haya resuelto los conflictos, este comando procede con la fusión. Si no se resolvieron algunos conflictos, este comando falla.

ma (m a, magit-merge-abort)

Este comando aborta la operación de fusión en curso.

Resolución de Conflictos

Cuando se fusionan ramas (o se combina o modifica el historial) pueden producirse conflictos. Si se editan dos partes completamente diferentes del mismo archivo en dos ramas y luego se fusiona una de estas ramas en la otra, Git puede resolverlo por sí mismo, pero si se edita la misma área de un archivo, entonces se requiere un humano para decidir cómo las dos versiones, o "lados del conflicto", deben combinarse en una sola.

Aquí sólo podemos ofrecer una breve introducción al tema e indicarle algunas herramientas que pueden servirle de ayuda. Si es nuevo en esto, consulte la documentación de Git, así como otros recursos.

Si un archivo tiene conflictos y Git no puede resolverlos por sí mismo, coloca ambas versiones en el archivo afectado junto con marcadores especiales cuyo propósito es denotar los límites de la parte no resuelta del archivo y entre las diferentes versiones. Estas líneas de separación comienzan con cadenas formadas por siete veces el mismo carácter, uno de <, |, = y >, y van seguidas de información sobre el origen de las respectivas versiones, por ejemplo

<<<<<<< HEAD
Toma la pastilla azul.
=======
Toma la píldora roja.
>>>>>>> característica

En este caso ha elegido tomar la píldora roja en una rama y en otra ha elegido la píldora azul. Ahora que está fusionando estas dos ramas divergentes, es imposible que Git sepa qué píldora quiere tomar.

Para resolver ese conflicto debe crear una versión de la zona afectada del archivo manteniendo sólo uno de los lados, posiblemente editándola para introducir los cambios del otro lado, eliminar las otras versiones así como los marcadores, y luego preparar el resultado (staged). Una posible solución podría ser:

Toma las dos pastillas.

A veces es útil ver no sólo los dos lados del conflicto, sino también la versión "original" de antes que la misma zona del archivo se modificara dos veces en ramas diferentes. De instrucciones a Git para que inserte también esa versión ejecutando este comando una vez:

git config --global merge.conflictStyle diff3

El conflicto anterior podría haber tenido este aspecto:

<<<<<<< HEAD
Tome la píldora azul.
||||||| fusiona (merge) ascendientes comunes
Tome la píldora azul o la roja, pero no ambas.
=======
Tome la píldora roja.
>>>>>>> característica

Si ese fuera el caso, la resolución de conflictos anterior no habría sido correcta, lo que demuestra por qué puede ser útil ver la versión original junto a las versiones en conflicto.

Puede llevar a cabo la resolución de conflictos completamente a mano, pero Emacs también proporciona algunos paquetes que ayudan en el proceso: Smerge, Ediff ((ediff)Top), y Emerge ((emacs)Emerge). Magit no proporciona sus propias herramientas para la resolución de conflictos, pero hace más cómodo el uso de Smerge y Ediff. (Ediff sustituye a Emerge, así que de cualquier forma, probablemente no se quiera usar este último ).

En el búfer de estado de Magit, los archivos con conflictos no resueltos aparecen en las secciones "Unstaged changes" (cambios no confirmados) y/o "Staged changes" (cambios confirmados). Llevan como prefijo la palabra "unmerged" (sin fusionar), que en este contexto es esencialmente un sinónimo de "unresolved" (sin resolver).

Al pulsar RETURN (RET) mientras el punto se encuentra en una sección de archivo de este tipo, se muestra un búfer que visita ese archivo, activa el modo de fusión (smerge-mode) en ese búfer y coloca el punto dentro de la primera área con conflictos. A continuación, debe resolver ese conflicto usando comandos de edición normales y/o comandos Smerge.

Desafortunadamente Smerge no tiene un manual, pero puede obtener una lista de comandos y vinculantes teclando Ctrl-c ^ Ctrl-h RETURN (C-c ^ C-h RET) mientras que el punto esté en un nombre de comando para leer su documentación.

Normalmente editaría una versión y luego le diría a Smerge que mantenga sólo esa versión. Use Ctrl-c ^m (C-c ^ m, smerge-keep-mine) para mantener la versión HEAD o Ctrl-c ^o (C-c ^ o, smerge-keep-other) para mantener la versión que sigue a ‘|||||||’. A continuación, use Ctrl-d ^n (C-c ^ n) para pasar a la siguiente área conflictiva del mismo archivo. Cuando haya terminado de resolver los conflictos, vuelva al búfer de estado de Magit. El archivo debería aparecer ahora como "modified" (modificado), y ya no como "unmerged" (sin fusionar), porque fusiona automáticamente el archivo cuando se guarda el búfer después de resolver el último conflicto.

Magit ahora envuelve los comandos Smerge mencionados, permitiéndote usar estos combinaciones de teclas sin tener que ir al buffer de visita de archivos. Además k (k, magit-discard) en un trozo con conflictos no resueltos pregunta qué lado mantener o, si el punto está en un lado, lo mantiene sin preguntar. De forma similar k en un fichero sin resolver pregunta qué lado mantener.

Alternativamente puede usar Ediff, que usa buffers separados para las diferentes versiones del fichero. Para resolver conflictos en un fichero usando Ediff pulse e mientras point esté sobre dicho fichero en el buffer de estado.

Ediff también puede usarse para otros fines. Para más información sobre cómo introducir Ediff desde Magit, véase Ediff. Explicar cómo usar Ediff está fuera del alcance de este manual, en su lugar vea (ediff)Top.

Si no está seguro de si debe usar Smerge o Ediff, use el primero. Su uso es mucho más fácil de entender, y excepto para conflictos realmente complejos, el segundo suele ser excesivo.

Reordenamiento (rebase)

Consulte también la página de manual de git-rebase(1). Para información sobre cómo resolver los conflictos que ocurren durante los reordenamientos vea la sección anterior.

r (r, magit-rebase)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Cuando no hay una reorganización en curso, el transitorio presenta los siguientes comandos de sufijo.

Usando uno de estos comandos se inicia una secuencia de reorganización. Puede que Git se detenga en algún punto del camino, bien porque Usted se lo haya ordenado, o bien porque la aplicación de una confirmación haya fallado debido a un conflicto. Cuando ocurre esto, el buffer de estado muestra información sobre la secuencia de reordenamiento en curso en una sección similar a la de registro. Ver Información sobre el Rebase en Curso.

Para información sobre el upstream y el push-remote, vea Dos Ramas Remotas.

rp (r p, magit-rebase-onto-pushremote)

Este comando vuelve a situar la rama actual en su push-remote (la reordena en la rama remota).

Con un argumento prefijo o cuando el push-remote no está configurado o es inutilizable, entonces deja que el Usuario configure primero el push-remote.

ru (r u, magit-rebase-onto-upstream)

Este comando hace un reordenamiento de la rama actual sobre su rama ascendente (upstream).

Con un argumento prefijo o cuando la rama ascendente no está configurada o no se puede utilizar, entonces deja que el Usuario la configure primero.

re (r e, magit-rebase-branch)

Este comando reordena la rama actual en una rama leída en el minibuffer. Todas las confirmaciones accesibles desde la cabecera pero no desde la rama TARGET seleccionada se vuelven a reordenar.

rs (r s, magit-rebase-subset)

Este comando inicia una secuencia de rebase no interactiva para transferir los commits de START a HEAD en NEWBASE. START debe seleccionarse de una lista de confirmaciones recientes.

Por defecto Magit usa el argumento --autostash, que hace que los cambios sin confirmar se almacenen en un stash (se oculte parte del archivo ) antes de que comience el reordenamiento. Estos cambios se restauran una vez finalizado el proceso y, si es posible, se elimina el stash. Si el stash no se aplica limpiamente, no se elimina. En caso de que algo vaya mal al resolver los conflictos, esto permite volver a empezar.

Aunque una de las acciones está dedicada a los reordenamientos interactivos, el transitorio también cuenta con el argumento infijo --interactive. Se puede usar para convertir una de las otras variantes de reordenamiento no interactivo en uno interactivo.

Por ejemplo, si desea limpiar una rama de características y al mismo tiempo volver a colocarla en master, podría usar r-iu. Pero le recomendamos que lo haga en dos pasos. En primer lugar, use ri para limpiar la rama de características, y luego en un segundo paso ru para reordenarla en master. De esta manera, si las cosas resultan ser más complicadas de lo que pensaba y/o se comete un error y hay que empezar de nuevo, sólo tendrá que rehacer la mitad del trabajo.

Habilitar explícitamente --interactive no tendrá efecto en los siguientes comandos, ya que siempre usan ese argumento de todos modos, incluso si no está habilitado en el transitorio.

ri (r i, magit-rebase-interactive)

Este comando inicia una secuencia interactiva de reordenamiento.

rf (r f, magit-rebase-autosquash)

Este comando combina confirmaciones de squash y fixup con sus objetivos previstos.

rm (r m, magit-rebase-edit-commit)

Este comando inicia una secuencia de reordenamiento interactivo que permite al Usuario editar una única confirmación anterior.

rw (r w, magit-rebase-reword-commit)

Este comando inicia una secuencia de reordenamiento interactivo que permite al Usuario reordenar una única confirmación anterior.

rk (r k, magit-rebase-remove-commit)

Este comando elimina una confirmación antigua usando reordenamiento.

Cuando se está llevando a cabo un reordenamiento, el transitorio presenta en su lugar los siguientes comandos de sufijo.

rr (r r)

Este comando reinicia la operación de cambio de reordenamiento actual.

En algunos casos aparece un mensaje de confirmación para que lo edite. Con un argumento prefijo, el mensaje antiguo se reutiliza tal cual.

rs (r s, magit-rebase-skip)

Este comando omite la confirmación actual y reinicia la operación de reordenamiento en curso.

re (r e, magit-rebase-edit)

Este comando permite al Usuario editar la lista de tareas pendientes de la operación de reordenamiento en curso.

ra (r a, magit-rebase-abort)

Este comando aborta la operación de reordenamiento actual, restaurando la rama original.

Secuencias de Edición de Reordenamiento

Ctrl-c Ctrl-c (C-c C-c, with-editor-finish)

Finaliza la sesión de edición actual devolviendo el código de salida 0. A continuación, Git usará las instrucciones de reordenamiento que encuentre en el archivo.

Ctrl-c Ctrl-k (C-c C-k, with-editor-cancel)

Cancela la sesión de edición actual devolviendo el código de salida 1. Git renuncia a iniciar la secuencia de reordenamiento.

RETURN (RET, git-rebase-show-commit)

Muestra la confirmación en la línea actual en otro búfer y selecciona ese búfer.

SPACE (SPC, git-rebase-show-or-scroll-up)

Muestra la confirmación en la línea actual en otro búfer sin seleccionarlo. Si el búfer de revisión ya está visible en otra ventana del marco actual, en su lugar desplaza esa ventana hacia arriba.

DEL (DEL, git-rebase-show-or-scroll-down)

Muestra la confirmación en la línea actual en otro búfer sin seleccionarlo. Si el búfer de revisión ya está visible en otra ventana del marco actual, en su lugar desplaza esa ventana hacia abajo.

p (p, git-rebase-backward-line)

Se mueve a la línea anterior.

n (n, git-rebase-forward-line)

Se mueve a la siguiente línea.

Alt-p (M-p, git-rebase-move-line-up)

Mueve la confirmación (o comando) actual hacia arriba

Alt-n (M-n, git-rebase-move-line-down)

Mueve la confirmación (o comando) actual hacia abajo.

r (r, git-rebase-reword)

Edita el mensaje de confirmación en la línea actual.

e (e, git-rebase-edit)

Se detiene en la confirmación de la línea actual.

s (s, git-rebase-squash)

Une la confirmación de la línea actual con la anterior y edita el mensaje.

f (f, git-rebase-fixup)

Une la confirmación de la línea actual con la confirmación anterior, descartando el mensaje de la confirmación en curso.

k (k, git-rebase-kill-line)

Cancela o finaliza la accion en la línea actual.

c (c, git-rebase-pick)

Usa la confirmación de la línea actual.

x (x, git-rebase-exec)

Inserta un comando shell que se ejecutará después de la confirmación.

Si ya existe una orden de este tipo en la línea actual, edítela en su lugar. Con un argumento prefijo inserta un nuevo comando incluso si ya hay uno en la línea actual. Con una entrada vacía elimina el comando de la línea actual, si existe.

b (b, git-rebase-break)

Inserta una acción de interrupción antes de la línea actual, indicando a Git que devuelva el control al Usuario.

y (y, git-rebase-insert)

Lee una confirmación arbitraria y la inserta debajo de la línea actual.

Ctrl-x u (C-x u, git-rebase-undo)

Deshace algunos cambios anteriores. Como deshacer pero funciona en buffers de sólo lectura.

Opción de Usuario: git-rebase-auto-advance

Define si se pasa a la línea siguiente después de cambiar una línea.

Opción de Usuario: git-rebase-show-instructions

Establece si se deben mostrar las instrucciones de uso dentro del buffer de rebase.

Opción de Usuario: git-rebase-confirm-cancel

Determina si se requiere confirmación para cancelar.

Cuando se realiza una reorganización con la opción --rebase-merges, la secuencia incluirá algunos otros tipos de acciones y los siguientes comandos se vuelven relevantes.

l (l, git-rebase-label)

Este comando inserta una acción de etiqueta o edita la que hay en el punto.

t (t, git-rebase-reset)

Este comando inserta una acción de reinicio o edita la que se encuentra en el punto. El prompt ofrecerá las etiquetas que están actualmente presentes en el buffer.

MM (M M, git-rebase-merge)

El comando inserta una acción de fusión o edita la que se encuentra en el punto. El prompt ofrecerá las etiquetas que están actualmente presentes en el buffer. No se admite la especificación de un mensaje para reutilizar mediante -c o -C; siempre se invocará a un editor para la fusión.

Mt (M t, git-rebase-merge-toggle-editmsg)

Este comando alterna entre las opciones -C y -c de la acción de fusión en el punto. Ambas opciones especifican una confirmación cuyo mensaje debe ser reutilizado. La variante con minúsculas indica a Git que invoque al editor al crear la fusión, permitiendo al Usuario editar el mensaje.

Información acerca de Reordenamiento en progreso

Mientras una secuencia de reorganización (rebase) se está llevando a cabo, el búfer de estado presenta una sección que lista las confirmaciones que ya se han aplicado, así como las confirmaciones que todavía tienen que aplicarse.

Las confirmaciones se dividen en dos mitades. Cuando el rebase se detiene en una confirmación, ya sea porque el Usuario tiene que lidiar con un conflicto o porque solicitó explícitamente que el reordenamiento se detuviera en esa confirmación, entonces el punto se coloca en la confirmación que separa los dos grupos, es decir, en HEAD. Las confirmaciones por encima de ella aún no se han aplicado, mientras que el HEAD y las confirmaciones por debajo de él ya se han aplicado. Entre estos dos grupos de confirmaciones aplicadas y por aplicar, a veces hay una confirmación que ha sido eliminada.

Cada confirmación va precedida de una palabra y estas palabras se muestran además en diferentes colores para indicar el estado de las confirmaciones.

Se usan los siguientes colores:

• Las confirmaciones que usan el mismo color de primer plano que la cara por defecto aún no se han aplicado.
• Las confirmaciones amarillas tienen alguna relación especial con la confirmación en la que se detuvo el rebase. Esto se usa para las palabras "join", "goal", "same" y "work" (ver más abajo).
• Las confirmaciones grises ya se han aplicado.
• La confirmación azul es la confirmación HEAD.
• La confirmación verde es la confirmación en la que se detuvo la secuencia rebase. Si se trata de la misma confirmación que HEAD (por ejemplo, porque aún no ha hecho nada después de que el reordenamiento se detuviera en la confirmación, entonces esta confirmación se muestra en azul, no en verde). Sólo puede haber una confirmación verde y una azul al mismo tiempo, si crea una o más confirmaciones nuevas después de que rebase se detenga en una confirmación.
• Las confirmaciones rojas se han eliminado. Se muestran sólo como referencia, por ejemplo, para facilitar la diferenciación.

Por supuesto, estos colores están sujetos al tema cromático en uso.

Se usan las siguientes palabras:

• Las confirmaciones prefijadas con pick, reword, edit, squash y fixup aún no se han aplicado. Estas palabras tienen el mismo significado aquí que en el buffer usado para editar la secuencia de reordenamiento. Consulte Secuencias de Edición de Reordenamiento. Cuando se especifica la opción --rebase-merges, también pueden aparecer las líneas reset, label y merge.
• Las confirmaciones prefijadas con done y onto ya han sido aplicadas. Es posible que dicha confirmación sea el HEAD, en cuyo caso es azul. En otro caso es gris.
  • La confirmación con el prefijo onto es la confirmación sobre la que se están re-aplicando todas las demás confirmaciones. Esta confirmación en sí no tuvo que ser re-aplicada, es la confirmación a la que el reordenamiento retrocedió antes de empezar a re-aplicar otras confirmaciones.
  • Las confirmaciones con el prefijo done ya han sido re-aplicadas. Esto incluye las confirmaciones que se han vuelto a aplicar, pero también las nuevas confirmaciones que se han creado durante el reordenamiento.
• Todas las demás confirmaciones, las que no llevan el prefijo de ninguna de las palabras anteriores, están relacionadas de algún modo con la confirmación en la que se detuvo el reordenamiento.
  Para determinar si se está ante una confirmación relacionada con la confirmación detenida, se comparan sus hashes, árboles (trees) y patch-ids ¹. El mensaje de confirmación no se utiliza para este propósito.
  En general, las confirmaciones que están relacionadas con la confirmación detenida pueden tener cualquiera de los colores usados, aunque no todas las combinaciones de color/palabra son posibles.

  Nota

  ¹ El patch-id es un hash de los cambios introducidos por una confirmación. Difiere del hash de la confirmación en sí, que es un hash del resultado de aplicar ese cambio (es decir, los árboles y blobs resultantes), así como información sobre el Autor y el Autor de la confirmación, el mensaje de confirmación y los hashes de los padres de la confirmación. Por otro lado, el hash patch-id se crea sólo a partir de las líneas añadidas y eliminadas, incluso los números de línea y los cambios en los espacios en blanco se ignoran al calcular este hash. Los patch-ids de dos confirmaciones pueden usarse para responder a la pregunta "¿Estas confirmaciones hacen el mismo cambio?".

• Las palabras usadas para las confirmaciones detenidas son:
  • Cuando una confirmación lleva el prefijo void, eso indica que Magit sabe con seguridad que todos los cambios de esa confirmación se han aplicado usando varias confirmaciones nuevas. Esta confirmación ya no es accesible desde HEAD, y tampoco es una de las confirmaciones que se aplicarán al reanudar la sesión.
  • Cuando una confirmación lleva el prefijo join, indica que la secuencia de reordenamiento se detuvo en esa confirmación debido a un conflicto: ahora hay que unir (fusionar) los cambios con lo que ya se ha aplicado. En cierto sentido, esta es la confirmación en la que se detuvo el rebase, pero aunque su efecto ya está en el índice y en el árbol de trabajo (con marcadores de conflicto), la confirmación en sí no se ha aplicado todavía (no es el HEAD). Así que se muestra en amarillo, como las otras confirmaciones que todavía tienen que aplicarse.
  • Cuando una confirmación lleva el prefijo stop o same con los colores azul o verde, eso indica que el reordenamiento se detuvo en esa confirmación, que aún se aplica o se ha vuelto a aplicar, y que al menos su patch-id no ha cambiado.
    • Cuando una confirmación tiene el prefijo stop, indica que rebase se detuvo en esa confirmación porque usted lo solicitó antes, y su patch-id no ha cambiado. Incluso podría ser exactamente la misma confirmación.
    • Cuando una confirmación tiene el prefijo same azul o verde, indica que su árbol o hash ha cambiado, pero no su patch-id. Si es azul, entonces es la confirmación HEAD (como siempre para el azul). Cuando es verde, entonces ya no es HEAD porque se han creado otras confirmaciones desde entonces (pero antes de continuar el reordenamiento).
  • Cuando una confirmación tiene el prefijo goal, same en amarillo, o work, eso indica que el reordenamiento aplicó esa confirmación pero que luego reseteó HEAD a una confirmación anterior (probablemente para dividirla en múltiples confirmaciones), y que quedan algunos cambios sin confirmar que probablemente (pero no necesariamente) se originan en esa confirmación.
    • Cuando una confirmación lleva el prefijo goal, indica que todavía es posible crear una nueva confirmación con exactamente el mismo árbol (el "goal") sin editar manualmente ningún fichero, confirmando el índice, o almacenando todos los cambios y confirmándolos. Este es el caso cuando el árbol original todavía existe en el índice o el árbol de trabajo está intacto.
    • Cuando el prefijo same de una confirmación es amarillo, indica que ya no es posible crear una confirmación con exactamente el mismo árbol, pero que todavía es posible crear una confirmación con el mismo parche-id. Este sería el caso si se creara una nueva confirmación con otros cambios, pero los cambios de la confirmación original aún existen en el índice o árbol de trabajo sin alterar.
    • Cuando una confirmación lleva el prefijo work, indica que se ha restablecido HEAD a una confirmación anterior, y que hay algunos cambios preparados y/o sin preparar (probablemente, pero no necesariamente) originados a partir de esa confirmación. Sin embargo, ya no es posible crear una nueva confirmación con el mismo árbol o, al menos, con el mismo patch-id, porque ya se han realizado otros cambios.
  • Cuando una confirmación tiene el prefijo poof o gone, eso indica que el reordenamiento aplicó esa confirmación pero que luego reseteó HEAD a una confirmación anterior (probablemente para dividirla en múltiples confirmaciones), y que no hay cambios no comprometidos.
    • Cuando una confirmación lleva el prefijo puf, indica que ya no es accesible desde HEAD, sino que ha sido reemplazada por una o más confirmaciones, que juntas tienen exactamente el mismo efecto.
    • Cuando una confirmación lleva el prefijo , indica que ya no es accesible desde HEAD y que tampoco podemos determinar si sus cambios siguen vigentes en uno o más confirmaciones nuevas. Puede ser, pero si es así, entonces también debe haber otros cambios que hacen que sea imposible saberlo con certeza.

No se preocupe si no entiende todo lo anterior. No pasa nada, adquirirá una comprensión lo suficientemente buena con la práctica.

Para otras operaciones de secuencias como "cherry-picking", se muestra una sección similar, pero carecen de algunas de las características descritas anteriormente, debido a limitaciones en los comandos git usados para implementarlas. Lo más importante es que estas secuencias sólo soportan "elegir" una confirmación, pero no otras acciones como "reescribir", y no hacen un seguimiento de las confirmaciones que ya se han aplicado.

Cherry Picking

Vea también git-cherry-pick

A (A, magit-cherry-pick)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Cuando no se está realizando ningún cherry-pick o revert, el transitorio presenta los siguientes comandos de sufijo.

AA (A A, magit-cherry-copy)

Este comando copia COMMITS (confirmaciones) de otra rama a la rama actual. Si la región selecciona varias confirmaciones, éstas se copian sin preguntar. En caso contrario, se pregunta al Usuario por una confirmación o rango, por defecto la confirmación en el punto.

Aa (A a, magit-cherry-apply)

Este comando aplica los cambios en las confirmaciones de otra rama a la rama actual. Si la región selecciona múltiples confirmaciones, entonces se usan esas, sin preguntar. En caso contrario, se pregunta al Usuario por una confirmación o rango, usando por defecto la confirmación en el punto.

Este comando también tiene un enlace de nivel superior, que puede invocarse sin usar el transitorio escribiendo a en el nivel superior.

Los siguientes comandos no sólo aplican algunas confirmaciones a una rama, sino que también las eliminan de otra rama. La eliminación se realiza usando git-update-ref o, si es necesario, git-rebase. Tanto aplicar confirmaciones como eliminarlas usando git-rebase puede llevar a conflictos. Si esto ocurre, entonces estos comandos se abortan y no sólo tendrá que resolver los conflictos, sino también terminar el proceso de la misma manera que lo haría si estos comandos no existieran en absoluto.

Ah (A h, magit-cherry-harvet)

Este comando mueve los COMMITS (confirmaciones) seleccionados que deben estar ubicados en otra BRANCH (rama) a la rama actual en su lugar, eliminándolos de la primera. Cuando este comando tiene éxito, la rama actual es la misma que antes.

Aplicar las confirmaciones en la rama actual o eliminarlas de la otra rama puede provocar conflictos. Cuando esto ocurre, este comando se detiene y debe resolver los conflictos y finalizar el proceso manualmente.

Ad (A d, magit-cherry-donate)

Este comando mueve los COMMITS (confirmaciones) seleccionados de la rama actual a otra BRANCH (rama) existente, eliminándolos de la primera. Cuando este comando tiene éxito, entonces la misma rama es actual como antes. Se permite que HEAD se desprenda inicialmente.

Aplicar las confirmaciones en la otra rama o eliminarlas de la rama actual puede provocar conflictos. Cuando esto sucede, entonces este comando se detiene y hay que resolver los conflictos y luego terminar el proceso manualmente.

An (A n, magit-cherry-spinout)

Este comando mueve los COMMITS (confirmaciones) seleccionados de la rama actual a una nueva rama BRANCH, eliminándolos de la anterior. Cuando este comando tiene éxito, la rama actual es la misma que antes.

Aplicar las confirmaciones en la otra rama o eliminarlas de la rama actual puede provocar conflictos. Cuando esto sucede, este comando se detiene y debe resolver los conflictos y finalizar el proceso manualmente.

As (A s, magit-cherry-spinoff)

Este comando mueve los COMMITS (confirmaciones) seleccionados de la rama actual a una nueva rama BRANCH, eliminándolos de la primera. Cuando este comando tiene éxito, la nueva rama se comprueba.

Aplicar las confirmaciones en la otra rama o eliminarlas de la rama actual puede provocar conflictos. Cuando esto sucede, este comando se detiene y tiene que resolver los conflictos y luego terminar el proceso manualmente.

Cuando se está realizando un cherry-pick o una reversión, el transitorio presenta en su lugar los siguientes comandos de sufijo.

AA (A A, magit-sequence-continue)

Reanuda la secuencia actual de cherry-pick o la revierte.

As (A s, magit-sequence-skip)

Omite la parada en la confirmación durante una secuencia cherry-pick o revierte.

Aa (A a, magit-sequence-abort)

Aborta la secuencia actual de cherry-pick o la revierte. Esto descarta todos los cambios realizados desde el inicio de la secuencia.

Revertir

V (V, magit-revert)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Cuando no se está realizando ningún cherry-pick o revert, el transitorio cuenta con los siguientes comandos de sufijo.

VV (V V, magit-revert-and-commit)

Revierte una confirmación creando una nueva. Pregunta por una confirmación, por defecto la que está en el punto. Si la región selecciona múltiples confirmaciones, entonces revierte todas ellas, sin preguntar.

Vv (V v, magit-revert-no-commit)

Revierte una confirmación aplicándola en sentido inverso al árbol de trabajo. Pregunta por una confirmación, por defecto la que está en el punto. Si la región selecciona múltiples confirmaciones, entonces revierte todas ellas, sin preguntar.

Cuando se está llevando a cabo un cherry-pick o una reversión, en su lugar el transitorio presenta los siguientes comandos de sufijo.

VA (V A, magit-sequence-continue)

Reanuda el actual cherry-pick o revierte la secuencia.

Vs (V s, magit-sequence-skip)

Omite la parada en la confirmación durante un cherry-pick o revierte la secuencia.

Va (V a, magit-sequence-abort)

Aborta el cherry-pick en curso o revierte la secuencia actual. Esto descarta todos los cambios realizados desde el inicio de la secuencia.

Reinicio

También vea la página de manual de git.

x (x, magit-reset-quickly)

Restablece el HEAD y el índice a alguna confirmación leída del Usuario y por defecto a la confirmación en el punto, y posiblemente también restablece el árbol de trabajo. Con un argumento prefijo reinicia el árbol de trabajo, de lo contrario no lo haga.

Xm (X m, magit-reset-mixed)

Restaura el HEAD y el índice a alguna confirmación leída del Usuario y por defecto a la confirmación en el punto. El árbol de trabajo se mantiene como está.

Xs (X s, magit-reset-soft)

Restablece el HEAD a alguna confirmación leída del Usuario y por defecto a la confirmación en el punto. El índice y el árbol de trabajo se mantienen tal cual.

Xh (X h, magit-reset-hard)

Restaura el HEAD, el índice y el árbol de trabajo a alguna confirmación leída por el Usuario y por defecto a la confirmación en el punto.

Xk (X k, magit-reset-keep)

Restablece el HEAD, el índice y el árbol de trabajo a alguna confirmación leída del Usuario y por defecto a la confirmación en el punto. Los cambios no confirmados se mantienen tal cual.

Xi (X i, magit-reset-index)

Restaura el índice a alguna confirmación leída por el Usuario y por defecto a la confirmación en el punto. Mantener el HEAD y el árbol de trabajo como están, así que si la confirmación se refiere al HEAD, entonces esto efectivamente deshace todos los cambios.

Xw (X w, magit-reset-worktree)

Restablece el árbol de trabajo a alguna confirmación leída del Usuario y por defecto a la confirmación en el punto. Mantenga el HEAD y el índice como están.

Xf (X f, )

Actualiza el fichero en el árbol de trabajo y el índice al contenido desde una revisión. Tanto la revisión como el fichero se leen desde el Usuario.

Stashing

Sería útil consultar también la pagina de manual de git al respecto.

z (z, magit-stash)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

zz (z z, magit-stash-both)

Crea un stash del índice y del árbol de trabajo (los oculta). Los archivos sin seguimiento se incluyen según los argumentos infix. Un argumento prefijo equivale a --include-untracked mientras que dos argumentos prefijo equivalen a --all.

zi (z i, magit-stash-index)

Crea un stash sólo del índice. Los cambios no organizados y no rastreados no se almacenan.

zw (z w, magit-stash-worktree)

Crea un alijo de cambios sin preparar en el árbol de trabajo. Los ficheros sin seguimiento se incluyen según los argumentos infix. Un argumento prefijo equivale a --include-untracked mientras que dos argumentos prefijo equivalen a --all.

zx (z x, magit-stash-keep-index)

Crea un stash del índice y del árbol de trabajo, manteniendo intacto el índice. Los archivos sin seguimiento se incluyen según los argumentos de infijo. Un argumento prefijo equivale a --include-untracked mientras que dos argumentos prefijo equivalen a --all.

zZ (z Z, magit-snapshot-both)

Crea una instantánea del índice y del árbol de trabajo. Los archivos sin seguimiento se incluyen según los argumentos infijos. Un argumento prefijo equivale a --include-untracked mientras que dos argumentos prefijo equivalen a --all.

zI (z I, magit-snapshot-index)

Crea una instantánea sólo del índice. Los cambios no almacenados y no rastreados no se almacenan.

zW (z W, magit-snapshot-worktree)

Crea una instantánea de los cambios no rastreados en el árbol de trabajo. Los archivos sin seguimiento se incluyen según los argumentos infijos. Un argumento prefijo equivale a --include-untracked mientras que dos argumentos prefijo equivalen a --all.

za (z a, magit-stash-apply)

Aplica un stash al árbol de trabajo. Intenta preservar el índice del stash. Si eso falla porque hay cambios por etapas, aplica sin preservar el índice stash.

zp (z p, magit-stash-pop)

Aplica un stash al árbol de trabajo y lo elimina de la lista de stash. Intenta conservar el índice del stash. Si esto falla porque hay cambios por etapas, aplica sin mantener el índice stash y no elimina el stash.

zk (z k, magit-stash-drop)

Elimina un stash de la lista de stash. Cuando la región está activa, ofrece soltar todos los stash contenidos.

zv (z v, magit-stash-show)

Muestra todos los diffs de un stash en un buffer.

zb (z b, magit-stash-branch)

Crea y extrae una nueva rama de un stash existente. La nueva rama comienza en la confirmación que estaba vigente cuando se creó el stash.

zB (z B, magit-stash-branch-here)

Crea y comprueba una nueva rama a partir de un stash existente. Usa la rama actual o HEAD como punto de partida de la nueva rama. A continuación, aplicar el stash, dejándolo caer si se aplica limpiamente.

zf (z f, magit-stash-format-patch)

Crea un parche a partir de STASH.

k (k, magit-stash-clear)

Elimina todos los stashes guardados en el reflog de REF borrando REF.

zl (z l, magit-stash-alist)

Lista todos los stashes de un buffer.

Opción de Usuario: magit-stashes-margin

Esta opción especifica si el margen se muestra inicialmente en los buffers de stashes y cómo se formatea.

El valor tiene la forma (INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH).

• Si INIT no es nulo, entonces el margen se muestra inicialmente.
• STYLE controla el formato de la fecha del autor o del confirmador. Puede ser age (para mostrar la edad de la confirmación), age-abbreviated (para abreviar la unidad de tiempo a un carácter), o una cadena (adecuada para format-time-string) para mostrar la fecha real. La opción magit-log-margin-show-committer-date controla qué fecha se muestra.
• WIDTH controla la anchura del margen. Esto existe por compatibilidad futura y actualmente el valor no debe cambiarse.
• AUTHOR controla si el nombre del autor también se muestra por defecto.
• AUTHOR-WIDTH debe ser un número entero. Cuando se muestra el nombre del autor, esto especifica cuánto espacio se usa para hacerlo.

Transferencia

Remotos

Comandos Remotos

El comando de prefijo transitorio magit-remote se usa para añadir remotas y hacer cambios en remotas existentes. Esta orden sólo se ocupa de las remotas en sí, no de las ramas ni de la transferencia de confirmaciones. Estas funciones están disponibles en otras órdenes transitorias.

Vea la página de manual de git.

M (M, magit-remote)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

Por defecto, también enlaza y muestra los valores de algunas variables Git relacionadas con el remoto y permite cambiar sus valores.

Opción de Usuario: magit-remote-direct-configure

Esta opción controla si las variables Git relacionadas con el remoto son accesibles directamente desde el transitorio magit-remote.

Si t (el valor por defecto) y una rama local se descarga, entonces magit-remote presenta las variables para la remota ascendente de esa rama, o si HEAD se descarga, para origen, siempre que exista.

Si es nil, hay que usar magit-remote-configure para hacerlo.

MC (M C, magit-remote-configure)

Este comando de prefijo transitorio vincula comandos que establecen el valor de variables relacionadas con remotas y las muestra en un búfer temporal hasta que se sale del transitorio.

Con un argumento de prefijo, este comando siempre solicita un remoto.

Sin un argumento de prefijo, depende de si se invocó como sufijo de magit-remote y de la opción magit-remote-direct-configure. Si magit-remote ya muestra las variables para el ascendente, no tiene sentido invocar otro transitorio que las muestre para el mismo remoto. En ese caso, este comando solicita una remota.

Las variables se describen en Variables Git remotas.

Ma (M a, magit-remote-add)

Este comando añade un repositorio remoto y obtiene toda la información que está en él (git fetch). El nombre remoto y la url se leen en el minibuffer.

Mr (M r, magit-remote-rename)

Este comando cambia el nombre de una rama remota. Tanto el nombre antiguo como el nuevo se leen en el minibuffer.

Mu (M u, magit-remote-set-url)

Este comando cambia la url de una rama remota. Tanto la remota como la nueva url se leen en el minibuffer.

Mk (M k, magit-remote-remove)

Este comando borra un repositorio remoto, leído en el minibuffer.

Mp (M p, magit-remote-prune)

Este comando elimina ramas de seguimiento remoto obsoletas para una lectura remota en el minibuffer.

MP (M P, magit-remote-prune-refspecs)

Esta orden elimina las refspecs obsoletas para una lectura remota en el minibuffer.

Una refspec está obsoleta si ya no existe al menos una rama en el remoto que sería obtenida debido a esa refspec. Una refspec obsoleta es problemática porque su existencia provoca que Git se niegue a realizar la búsqueda de acuerdo con las refspecs obsoletas restantes.

Si sólo quedan refspecs obsoletos, este comando ofrece eliminar el remoto o sustituir los refspecs obsoletos por el refspec por defecto ("+refs/heads/*:refs/remotes/REMOTE/*").

Este comando también elimina las ramas de seguimiento remoto que se crearon debido a las refspecs ahora obsoletas. Las demás ramas obsoletas no se eliminan.

Opción de Usuario: magit-remote-add-set-remote.pushDefault

Esta opción controla si se pregunta al Usuario sobre si quiere establecer remote.pushDefault después de añadir un control remoto.

Si es ask, siempre se pregunta al Usuario. Si ask-if-unset, sólo se pregunta al Usuario si la variable no está ya establecida. Si es nil, no se pregunta al Usuario y no se establece la variable. Si el valor es una cadena, la variable se establece sin preguntar, siempre que el nombre del remoto añadido sea igual a esa cadena y la variable no esté ya establecida.

Variables Git remotas

Estas variables pueden establecerse desde el comando de prefijo transitorio magit-remote-configure. Por defecto, también se pueden configurar desde magit-remote. Ver Comandos Remotos.

Variable: remote.NOMBRE.url

Esta variable especifica la url de la remota denominada NOMBRE. Puede tener múltiples valores.

Variable: remote.NAME.fetch

La refspec usada cuando se obtiene del nombre remoto NAME. Puede tener varios valores.

Variable: remote.NOMBRE.pushurl

Esta variable especifica la url usada para enviar al remoto llamado NOMBRE. Si no se especifica, se utiliza remote. NOMBRE.url en su lugar. Puede tener varios valores.

Variable: remote.NOMBRE.push

La refspec usada cuando se envía al nombre remoto NOMBRE. Puede tener varios valores.

Variable: remote.NOMBRE.tagOpts

Esta variable especifica qué etiquetas se obtienen por defecto. Si el valor es --no-tags, no se obtiene ninguna etiqueta. Si el valor es --tags, se obtendrán todas las etiquetas. Si esta variable no tiene ningún valor, sólo se obtendrán las etiquetas accesibles desde las ramas obtenidas.

Fetching

Consulte también la página de manual de git-fetch(1). Para más información sobre el upstream y el push-remote, vea Dos ramas remotas.

f (f, magit-fetch)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

fp (f p, magit-fetch-from-pushremote)

Este comando obtiene información del push-remote actual.

Con un argumento prefijo o cuando el push-remote no está configurado o es inutilizable, entonces deja que el Usuario configure primero el push-remote.

fu (f u, magit-fetch-from-upstream)

Este comando busca en el ascendente (upstream) de la rama actual.

Si el upstream está configurado para la rama actual y nombra un remoto existente, entonces lo utiliza. Si no, intenta usar otro remoto: Si sólo hay configurado un directorio remoto, se utiliza éste. Si existe un remoto llamado "origen", se usará ese.

Si no se puede determinar ningún remoto, este comando no está disponible desde el prefijo transitorio magit-fetch y al invocarlo directamente se produce un error.

fe (f e, magit-fetch-other)

Este comando obtiene información de un repositorio leído desde el minibuffer.

fo (f o, magit-fetch-branch)

Este comando obtiene una rama desde una remota, ambas se leen desde el minibuffer.

fr (f r, magit-fetch-refspec)

Este comando obtiene información de un remoto usando una refspec explícita, ambas leídas del minibuffer.

fa (f a, magit-fetch-all)

Este comando busca en todas los remotos.

fm (f m, magit-submodule-fetch)

Este comando recupera todos los submódulos. Con un prefijo como argumento, obtiene todas los remotos de todos los submódulos.

Opción de Usuario: magit-pull-or-fetch

Por defecto, los comandos fetch y pull están disponibles desde un comando prefijo transient separado. Establecerlo a t añade algunos (pero no todos) de los comandos sufijo anteriores al transient magit-pull.

Si lo hace, es posible que también desee cambiar la vinculación de teclas para estos comandos prefijo, por ejemplo:

(setq magit-pull-or-fetch t)
(define-key magit-mode-map "f" 'magit-pull) ; era magit-fetch
(define-key magit-mode-map "F" nil)         ; era magit-pull
	

Pulling

Consulta la página de manual de git-pull(1). Para más información sobre la rama ascendente (upstream) y el push-remote, vea Dos ramas remotas.

F (F, magit-pull)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

Fp (F p, magit-pull-from-pushremote)

Este comando obtiene información del push-remote de la rama actual.

Con un argumento prefijo o cuando el push-remote no está configurado o no se puede usar, entonces deja que el Usuario configure primero el push-remote.

Fu (F u, magit-pull-from-upstream)

Este comando extrae de la rama ascendente (upstream) de la rama actual.

Con un argumento prefijo o cuando el upstream no está configurado o no es utilizable, entonces deja que el Usuario configure primero el upstream.

Fe (F e, magit-pull-branch)

Este comando obtiene información de una rama leída en el minibuffer.

Pushing

Consulte también la página de manual de git-push(1). Para más información sobre la rama ascedente (upstream) y el push-remote, vea Dos ramas remotos.

P (P, magit-push)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Pp (P p, magit-push-current-to-pushremote)

Este comando empuja la rama actual a su push-remote.

Con un argumento prefijo o cuando el push-remote no está configurado o es inutilizable, entonces deja que el Usuario configure primero el push-remote.

Pu (P u, magit-push-current-to-stream)

Este comando empuja la rama actual a su rama upstream.

Con un argumento prefijo o cuando la rama ascendente no está configurada o no se puede utilizar, entonces deja que el Usuario configure primero la rama ascendente.

Pe (P e, magit-push-current)

Este comando empuja la rama actual a una rama leída en el minibuffer.

Po (P o, magit-push-other)

Este comando empuja una rama arbitraria o una confirmación a algún lugar. Tanto el origen como el destino se leen en el minibuffer.

Pr (P r, magit-push-refspecs)

Este comando envía una o varias refspecs a una remota, que se leen en el minibuffer.

Para utilizar varias refspecs, sepárelas con comas. La finalización sólo está disponible para la parte anterior a los dos puntos, o cuando no se usan dos puntos.

Pm (P m, magit-push-matching)

Este comando empuja todas las ramas coincidentes a otro repositorio.

Si sólo existe un repositorio remoto, entonces envíelo a ese repositorio. Si no, pide un repositorio remoto, ofreciendo por defecto el repositorio remoto configurado para la rama actual.

Pt (P t, magit-push-tagas)

Este comando empuja todas las etiquetas a otro repositorio.

Si sólo existe un repositorio remoto, lo envía a ese repositorio. Si no, pide un repositorio remoto, ofreciendo por defecto el repositorio remoto configurado para la rama actual.

PT (P T, magit-push-tag)

Este comando empuja una etiqueta a otro repositorio.

Uno de los argumentos de infijo, --force-with-lease, merece una palabra de advertencia. Se pasa sin un valor, lo que significa "permite un push forzado siempre que las ramas de rastreo remoto coincidan con sus homólogas en el extremo remoto". Si ha configurado una herramienta para realizar búsquedas automáticas (Magit por sí mismo no proporciona tal funcionalidad), usar --force-with-lease puede ser peligroso porque en realidad no controla ni conoce el estado de las referencias de rastreo remoto. En ese caso, se debería considerar establecer push.useForceIfIncludes a true (disponible desde Git 2.30).

Existen dos comandos push más, que por defecto no están disponibles desde el transitorio push. Consulte sus doc-strings para obtener instrucciones sobre cómo añadirlos al transitorio.

Comando: magit-push-implicity argumento

Este comando empuja a algún sitio sin usar una refspec explícita.

Simplemente ejecuta git push -v [ARGS]. ARGS son los argumentos infijos. No se usan argumentos refspec explícitos. En su lugar, el comportamiento depende de al menos estas variables Git: push.default, remote.pushDefault, branch.<branch>.pushRemote, branch.<branch>.remote, branch.<branch>.merge, y remote.<remote>.push.

Si añade este sufijo a un prefijo transitorio sin especificar explícitamente la descripción, se intenta predecir lo que hará este comando. Por ejemplo:

(transient-insert-suffix 'magit-push \"p\"
  '(\"i\" magit-push-implicitly))"
	

Comando: magit-push-remote argumento remoto

Este comando envía al remoto REMOTE sin usar una refspec explícita. El remoto se lee en el minibuffer.

Este comando simplemente ejecuta git push -v [ARGS] REMOTE. ARGS son los argumentos infijos. No se usan argumentos refspec. En su lugar, el comportamiento depende de al menos estas variables Git: push.default, remote.pushDefault, branch.<branch>.pushRemote, branch.<branch>.remote, branch.<branch>.merge, y remote.<remote>.push.

Parches Planos

W (W, magit-patch)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Wc (W c, magit-patch-create)

Este comando crea parches para un conjunto de confirmaciones (commits). Si la región marca varios commits, entonces crea parches para todos ellos. De lo contrario, funciona como un comando prefijo transitorio, que cuenta con varios argumentos infijos y se invoca a sí mismo como un comando sufijo. Cuando este comando se invoca como sufijo de sí mismo, entonces crea un parche usando los argumentos infijos especificados.

Wa (W a, magit-patch-apply)

Este comando aplica un parche. Se trata de un comando prefijo transitorio, que presenta varios argumentos infijos y se invoca a sí mismo como comando sufijo. Cuando este comando se invoca como sufijo de sí mismo, entonces aplica un parche usando los argumentos infijos especificados.

Ws (W s, magit-patch-save)

Este comando crea un parche a partir del diff actual.

Dentro de los buffers magit-diff-mode o magit-revision-mode, C-x C-w también está ligado a este comando.

También es posible guardar un archivo de parche plano usando C-x C-w dentro de un búfer magit-diff-mode o magit-revision-mode.

Parches de Maildir

Consulte también la página de manual git-am(1) y la página de manual git-apply(1).

w (w, magit-am)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

ww (w w, magit-am-apply-patches)

Este comando aplica uno o más parches. Si la región marca archivos, éstos se aplican como parches. De lo contrario, lee un nombre de archivo en el minibuffer, por defecto el archivo en el punto.

wm (w m, magit-am-apply-maildir)

Este comando aplica parches desde un maildir.

wa (w a, magit-patch-apply)

Este comando aplica un parche simple. Para una descripción más detallada, consulte Parches simples. Este comando sólo está disponible desde el transitorio magit-am por razones históricas.

Cuando una operación "am" está en curso, el transitorio presenta en su lugar los siguientes comandos de sufijo.

ww (w w, magit-am-continue)

Este comando reanuda la secuencia actual de aplicación de parches.

ws (w s, magit-am-skip)

Este comando omite la parada en patch durante una secuencia de aplicación de parches.

wa (w a, magit-am-abort)

Este comando aborta la secuencia actual de aplicación de parches. Esto descarta todos los cambios introducidos desde que se inició la secuencia.

Otros

Etiquetado

Vea la página de manual git correspondiente.

t (t, magit-tag)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

tt (t t, magit-tag-create)

Este comando crea una nueva etiqueta con el NOMBRE dado en REV. Con un argumento prefijo crea una etiqueta anotada.

tr (t r, magit-tag-release)

Este comando crea una etiqueta de lanzamiento. Asume que las etiquetas de versión coinciden con magit-release-tag-regexp.

Primero pregunta por el nombre de la nueva etiqueta usando como referencia a la etiqueta con número de versión más alto existente y dejando que el Usuario incremente la parte deseada de la cadena de versión. Si usa etiquetas de versión o números de versión no convencionales (por ejemplo, v1.2.3-custom.1), puede configurar las variables magit-release-tag-regexp y magit-tag-version-regexp-alist.

Si se activa --annotate, se solicita el mensaje de la nueva etiqueta. El mensaje de etiqueta propuesto se basa en el mensaje de la etiqueta más alta, siempre que contenga la cadena de versión correspondiente y sustituyéndola por la cadena de versión nueva. De lo contrario, propone algo como "Foo-Bar 1.2.3", dado, por ejemplo, un TAG "v1.2.3" y un repositorio ubicado en algo como "/ruta/a/foo-bar".

tk (t k, magit-tag-delete)

Este comando borra una o varias etiquetas. Si la región marca varias etiquetas (y nada más), ofrece borrarlas. De lo contrario, solicita que se elimine una sola etiqueta, por defecto la etiqueta en el punto.

tp (t p, magit-tag-prune)

Este comando ofrece borrar las etiquetas que faltan localmente desde REMOTE, y viceversa.

Notas

Vea la página de manual de git correspondiente.

T (T, magit-notes)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

TT (T T, magit-notes-edit)

Edita la nota adjunta a una confirmación, por defecto a la confirmación en el punto.

Por defecto usa el valor de la variable Git core.notesRef o "refs/notes/commits" si no está definida.

Tr (T r, magit-notes-remove)

Elimina la nota adjunta a una confirmación, usando por defecto la confirmación en el punto.

Por defecto usa el valor de la variable Git core.notesRef o "refs/notes/commits" si no está definida.

Tp (T p, magit-notes-prune)

Elimina las notas sobre confirmaciones inaccesibles.

Es posible fusionar una referencia de nota con otra. Esto puede dar lugar a conflictos que deben resolverse en el árbol de trabajo temporal ".git/NOTES_MERGE_WORKTREE".

Tm (T m, magit-notes-merge)

Fusiona las notas de una ref leída del Usuario en la ref de notas actual. La referencia de notas actual es el valor de la variable Git core.notesRef o "refs/notes/commits" si no está definida.

Cuando una fusión de notas está en curso, el transitorio presenta los siguientes comandos de sufijo, en lugar de los enumerados anteriormente.

Tc (T c, magit-notes-merge-commit)

Confirma la fusión de las notas actuales, después de resolver manualmente los conflictos.

Ta (T a, magit-notes-merge-abort)

Abortar la fusión de notas actual.

Las siguientes variables controlan qué notas de referencia magit-notes-*, git notes y git show actúan y muestran. Tanto los valores locales como los globales se muestran y pueden modificarse.

Variable: core.notesRef

Esta variable especifica la ref de notas que se muestra por defecto y sobre la que actúan los comandos por defecto.

Variable: notes.displayRef

Esta variable especifica la referencia de notas adicional que se mostrará además de la especificada por core.notesRef. Puede tener múltiples valores y puede terminar con * para mostrar todas las refs en el espacio de nombres refs/notes/ (o ** si algunos nombres contienen barras inclinadas).

Submodulos

Vea la página de manual de git correspondiente.

Listado de submódulos

La orden magit-list-submodules muestra una lista de los submódulos del repositorio actual en un buffer separado. También es posible mostrar información sobre los submódulos directamente en el búfer de estado del superrepositorio añadiendo magit-insert-modules al gancho magit-status-sections-hook como se describe en Secciones del módulo de estado.

Comando: magit-list-submodules

Este comando muestra una lista de los submódulos poblados del repositorio actual en un buffer separado.

Puede invocarse pulsando RETURN (RET) en la sección titulada "Módulos".

Comando: magit-submodules-list-columns

Esta opción controla qué columnas muestra el comando magit-list-submodules y cómo se muestran.

Cada elemento tiene la forma (HEADER WIDTH FORMAT PROPS).

HEADER es la cadena que se muestra en la cabecera. WIDTH es la anchura de la columna. FORMAT es una función que se llama con un argumento, la identificación del repositorio (normalmente su nombre base), y con default-directory vinculado al nivel superior de su árbol de trabajo. Debe devolver una cadena a insertar o nil. PROPS es una lista que soporta las claves :right-align, :pad-right y :sort.

La función :sort tiene una interfaz extraña descrita en el docstring de tabulated-list-get-sort. Alternativamente < y magit-repolist-version< pueden ser usadas ya que esas funciones son automáticamente reemplazadas por funciones que satisfacen la interfaz. Establezca :sort como nil para inhibir la ordenación; si no se especifica, la columna se puede ordenar utilizando el ordenador predeterminado.

Es posible que desee mostrar un rango de columnas numéricas usando sólo un carácter por columna y sin ningún relleno entre columnas, en cuyo caso debe utilizar un HEADER apropiado, establecer WIDTH a 1, y establecer :pad-right a 9. Los números superiores a 9 se sustituyen por +.

Submódulo Transitorio

o (o, magit-submodule)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Algunos de los siguientes comandos actúan por defecto sobre los módulos seleccionados mediante la región. En aras de la brevedad, en su descripción se habla de "los módulos seleccionados", pero si no hay ningún módulo seleccionado, actúan sobre el módulo actual, o si el punto no está en ningún módulo, leen un único módulo sobre el que actuar. Con un argumento prefijo, estos comandos ignoran la selección y el módulo actual y actúan sobre todos los módulos adecuados.

oa (o a, magit-submodule-add)

Este comando añade el repositorio en la URL como un módulo. PATH opcional es la ruta al módulo relativa a la raíz del superproyecto. Si es nil entonces la ruta se determina en base a la URL.

or (o r, magit-submodule-register)

Este comando registra los módulos seleccionados copiando sus urls desde ".gitmodules" a "$GIT_DIR/config". Estos valores pueden editarse antes de ejecutar magit-submodule-populate. Si no necesita editar ninguna url, use directamente esta última.

op (o p, magit-submodule-populate)

Este comando crea el o los directorio/s de trabajo de los módulos seleccionados, comprobando las confirmaciones registradas.

ou (o u, magit-submodule-update)

Este comando actualiza los módulos seleccionados comprobando las confirmaciones registradas.

os (o s, magit-submodule-synchronize)

Este comando sincroniza las urls de los módulos seleccionados, copiando los valores de ".gitmodules" al ".git/config" del superproyecto así como los de los módulos.

od (o d, magit-submodule-unpopulate)

Este comando elimina el directorio de trabajo de los módulos seleccionados.

ol (o l, magit-list-submodule)

Este comando muestra una lista de los módulos del repositorio actual.

of (o f, magit-fetch-modules)

Este comando recupera todos los módulos más densos.

La opción magit-fetch-modules-jobs controla cuántos submódulos se obtienen en paralelo. También recupera el super-repositorio, porque git fetch no permite no hacerlo. Con un argumento prefijo se obtienen todos los remotos.

Subárbol

Consulte también la página de manual git-subtree(1).

O (O, magit-subtree)

Este comando de prefijo transitorio une los dos sub-transitorios; uno para importar un subárbol y otro para exportar un subárbol.

Oi (O i, magit-subtree-import)

Este comando de prefijo transitorio une los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Los sufijos de este comando importan subárboles.

Si se establece el argumento --prefix, los comandos de sufijo usan ese prefijo sin preguntar al Usuario. Si no se establece, entonces leen el prefijo en el minibuffer.

Oia (O i a, magit-subtree-add)

Este comando añade COMMIT desde REPOSITORY como un nuevo subárbol en PREFIX.

Oic (O i c, magit-subtree-add-commit)

Este comando añade COMMIT como un nuevo subárbol en PREFIX.

Oim (O i m, magit-subtree-merge)

Este comando fusiona COMMIT en el subárbol PREFIX.

Oif (O i f, magit-subtree-pull)

Este comando extrae COMMIT de REPOSITORY al subárbol PREFIX.

Oe (O e, magit-subtree-export)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Los sufijos de este comando exportan subárboles.

Si se establece el argumento --prefix, los comandos de sufijo usan ese prefijo sin preguntar al Usuario. Si no lo está, leen el prefijo en el minibuffer.

Oep (O e p, magit-subtree-push)

Este comando extrae el historial del subárbol PREFIX y lo empuja a REF en REPOSITORIO.

Oes (O e s, magit-subtree-split)

Este comando extrae el historial del subárbol PREFIX.

Árbol de Trabajo

Vea también la página de manual de git.

Z (Z, magit-worktree)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

Zb (Z b, magit-worktree-checkout)

Comprueba BRANCH (rama) en un nuevo árbol de trabajo en PATH.

Zc (Z c, magit-worktree-branch)

Crea un nuevo BRANCH (una rama) y comprueba su funcionamiento en un nuevo árbol de trabajo en PATH.

Zm (Z m, magit-worktree-delete)

Mueve un árbol de trabajo existente a un nuevo PATH (ruta).

Zk (Z k, magit-worktree-status)

Borra un árbol de trabajo, por defecto el árbol de trabajo en el punto. El árbol de trabajo primario no se puede eliminar.

Zg (Z g, magit-worktree-status)

Muestra el estado del árbol de trabajo en el punto.

Si no hay árbol de trabajo en el punto, lee uno en el minibuffer. Si el árbol de trabajo en el punto es aquel cuyo estado ya se está mostrando en el búfer actual, en su lugar lo muestra en Dired.

Comprobación de árbol de trabajo dispersa (sparse checkout)

Las comprobaciones dispersas permiten restringir el árbol de trabajo a un subconjunto de directorios. Consulte la página de manual git-sparse-checkout(1).

Advertencia: Git introdujo el comando git sparse-checkout en la versión 2.25 y aún lo anuncia como experimental y sujeto a cambios. La interfaz de Magit debería considerarse igual. En particular, si Git introduce un cambio incompatible con versiones anteriores, la funcionalidad sparse checkout de Magit puede actualizarse de forma que requiera una versión de Git más reciente.

> (>, magit-sparse-checkout)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

>e (> e, magit-sparse-checkout-enable)

Este comando inicializa una comprobación dispersa que sólo incluye los archivos del directorio de nivel superior.

Tenga en cuenta que magit-sparse-checkout-set y magit-sparse-checkout-add inicializan automáticamente una salida dispersa si es necesario. Sin embargo, puede que quiera llamar a magit-sparse-checkout-enable explícitamente para reinicializar una sparse checkout después de llamar a magit-sparse-checkout-disable, para pasar argumentos adicionales a git sparse-checkout init, o para ejecutar la inicialización de forma asíncrona.

>s (> s, magit-sparse-checkout-set)

Este comando toma una lista de directorios y configura la comprobación dispersa para incluir sólo los archivos en esos subdirectorios. Cualquier directorio incluido previamente se excluye a menos que se encuentre en la lista de directorios proporcionada.

>a (> a, magit-sparse-checkout-add)

Esta orden es como magit-sparse-checkout-set, pero añade la lista de directorios especificada al conjunto de directorios que ya está incluido en la comprobación dispersa.

>r (> r, magit-sparse-checkout-reapply)

Este comando aplica los patrones de comprobación dispersos configurados actualmente al árbol de trabajo. Esto es útil si se han extraído archivos excluidos después de operaciones como la fusión (merging) o una reorganización (rebasing).

>d (> d, magit-sparse-checkout-disable)

Este comando restaura la comprobación completa. Para volver a la comprobación dispersa anterior, llame a magit-sparse-checkout-enable.

Un sparse checkout también puede iniciarse cuando se clona un repositorio usando el comando magit-clone-sparse en el transitorio magit-clone (ver Clonando un repositorio).

Si desea que el búfer de estado indique cuándo se activa una comprobación dispersa, añada la función magit-sparse-checkout-insert-header a magit-status-headers-hook.

Bundle (paquete)

Vea también la página de manual de git referida.

Comando: magit-bundle

Este comando de prefijo transitorio enlaza varios comandos de sufijo para ejecutar subcomandos de git bundle y los muestra en un búfer temporal hasta que se invoque un sufijo.

Comandos comunes

Comando: magit-switch-to-repository-buffer
Comando: magit-switch-to-repository-buffer-other-window
Comando: magit-switch-to-repository-buffer-other-frame
Comando: magit-display-repository-buffer

Estos comandos leen cualquier búfer Magit existente que pertenezca al repositorio actual del usuario y luego cambian al búfer seleccionado (sin refrescarlo).

La última variante usa magit-display-buffer para hacerlo y, por tanto, respeta magit-display-buffer-function.

Estos son algunos de los comandos que se pueden usar en todos los buffers cuyos modos mayores derivan de magit-mode. Hay otros comandos comunes además de los de abajo, pero estos no encajaban bien en ningún otro sitio.

Ctrl-w (C w, magit-copy-section-value)

Esta orden guarda el valor de la sección actual en el anillo de muertes (kill-ring), y, siempre que la sección actual sea una sección confirmada, rama o etiqueta, también empuja la revisión (referenciada) a la pila magit-revision-stack.

Cuando la sección actual es una rama o una etiqueta, y se usa un argumento de prefijo, guarda la revisión en el extremo del anillo de muertes en lugar del nombre de referencia.

Cuando la región está activa, este comando la guarda en el kill-ring, como lo haría kill-ring-save, en lugar de comportarse como se ha descrito anteriormente. Si se usa un argumento de prefijo y la región está dentro de un trozo, elimina la columna del marcador de diferencias y mantiene sólo las líneas añadidas o eliminadas, dependiendo del signo del argumento de prefijo.

Alt-w (M w, magit-copy-buffer-revision)

Este comando guarda en el kill-ring la revisión que se está mostrando en el búfer actual y también la empuja a la pila magit-revision-stack. Está pensado principalmente para su uso en buffers magit-revision-mode, los únicos buffers en los que siempre es inequívoco qué revisión debe guardarse exactamente.

La mayoría de los otros buffers Magit suelen mostrar más de una revisión, de una forma u otra, por lo que este comando tiene que seleccionar una de ellas, y esa elección puede no ser siempre la que pensamos que hubiera sido la mejor elección.

Fuera de Magit, M-w y C-w suelen estar vinculados a kill-ring-save y kill-region, estos comandos también serían útiles en los buffers de Magit. Por lo tanto, cuando la región está activa, estos dos comandos se comportan como kill-ring-save en lugar de como se ha descrito anteriormente.

Modos de limpieza

Git mantiene los cambios confirmados el tiempo suficiente para que los Usuarios puedan recuperar los cambios que hayan borrado accidentalmente. Para ello, no recoge los objetos confirmados pero ya no referenciados (garbage) durante un cierto periodo de tiempo, por defecto 30 días.

Pero Git no hace un seguimiento de los cambios sin confirmar· en el árbol de trabajo y ni siquiera en el índice (el área de preparación (staging area)). Debido a que Magit hace que sea tan conveniente modificar los cambios no confirmados, también hace que sea fácil dispararse en el pie en el proceso.

Por esa razón, Magit proporciona un modo global que guarda los archivos rastreados en referencias de trabajo en curso después o antes de determinadas acciones. (En la actualidad, los archivos no rastreados nunca se guardan y, por razones técnicas, no se guarda nada antes de que se haya creado la primera confirmación).

Se usan dos referencias de trabajo en curso separadas para seguir el estado del índice y del árbol de trabajo: refs/wip/index/<branchref> y refs/wip/wtree/<branchref>, donde <branchref> es la referencia completa de la rama actual, por ejemplo, refs/heads/master. Cuando se separa la HEAD, se usa HEAD en lugar de <branchref>.

La consulta de otra rama (o la separación de HEAD) provoca el uso de diferentes wip refs (referencias a las limpiezas) para los cambios posteriores.

Opción de Usuario: magit-wip-mode

Cuando este modo está activado, los cambios no confirmados se confirman en las referencias de trabajo en curso dedicadas siempre que sea apropiado (es decir, cuando de otro modo, la pérdida de datos sería una posibilidad ).

Establecer esta variable directamente no tiene efecto; use la interfaz personalizada para hacerlo o llame a la función de modo correspondiente.

Por razones históricas, este modo está implementado sobre otros cuatro modos magit-wip-*, que también pueden usarse individualmente, si se desea un control más preciso sobre cuándo se actualizan las referencias wip; pero esto se desaconseja. Ver Legacy Wip Modes.

Para ver el registro de una rama y sus wip refs use los comandos magit-wip-log y magit-wip-log-current. Debería usar --graph cuando use estos comandos.

Comando: magit-wip-log

Este comando muestra el log de una rama y sus wip refs. Con un argumento prefijo negativo sólo se muestra la referencia wip del árbol de trabajo.

El valor numérico absoluto del argumento prefix controla cuántas "ramas" de cada wip ref se muestran. Esto sólo es relevante si el valor de magit-wip-merge-branch es nil.

Comando: magit-wip-log-current

Este comando muestra el log de la rama actual y sus wip refs. Con un argumento prefijo negativo sólo se muestra la referencia wip del árbol de trabajo.

El valor numérico absoluto del argumento prefix controla cuántas "ramas" de cada wip ref se muestran. Esto sólo es relevante si el valor de magit-wip-merge-branch es nil.

Xw (X w, magit-reset-worktree)

Este comando restablece el árbol de trabajo a alguna confirmación del usuario leída y por defecto a la confirmación en el punto, mientras que mantiene el HEAD y el índice como están.

Esto puede usarse para restaurar archivos al estado confirmado en un wip ref. Tenga en cuenta que esto descartará cualquier cambio sin confirmar que pudiera haber existido antes de invocar este comando (pero, por supuesto, sólo después de confirmarlo en el árbol de trabajo wip ref).

Tenga en cuenta que incluso si activa magit-wip-mode esto no le dará una protección perfecta. El escenario más probable para perder cambios a pesar del uso de magit-wip-mode es hacer un cambio fuera de Emacs y luego destruirlo también fuera de Emacs. En un escenario así, Magit, siendo un paquete de Emacs, no tuvo la oportunidad de evitar que se disparara en el pie.

Cuando no esté seguro de si Magit ha confirmado un cambio en los wip refs, puede solicitar explícitamente que se confirmen todos los cambios en todos los ficheros rastreados.

Alt-x magit-wip-commit (M-x magit-wip-commit)

Este comando confirma todos los cambios de todos los ficheros rastreados en el índice y en las referencias de trabajo en curso del árbol de trabajo. Al igual que los modos descritos anteriormente, no confirma los archivos no seguidos, pero comprueba todos los archivos seguidos en busca de cambios. Use este comando cuando sospeche que los modos pueden haber pasado por alto un cambio hecho fuera de Emacs/Magit.

Opción de Usuario: magit-wip-namespace

El espacio de nombres usado para las referencias de trabajo en curso. Debe terminar con una barra. Los wip refs se llaman <namespace>index/<branchref> y <namespace>wtree/<branchref>. Cuando se crean instantáneas mientras la cabecera (HEAD) está separada, se usa HEAD en lugar de <branchref>.

Opción de Usuario: magit-wip-mode--lighter

Modo de línea para magit-wip--mode.

Gráfico de barrido

Esta opción controla si la rama actual se fusiona en las refs de wip después de crear una nueva confirmación en la rama.

Si no es nula y la rama actual tiene nuevas confirmaciones, entonces se fusiona en la referencia wip antes de crear una nueva confirmación wip. Esto facilita la inspección del historial de wip y las confirmaciones wip nunca son recolectadas.

Si es nil y la rama actual tiene nuevas confirmaciones, la referencia wip se reinicia en el extremo de la rama antes de crear una nueva confirmación wip. Con esta configuración, las confirmaciones wip son, eventualmente, recogidos de la basura.

Cuando magit-wip-merge-branch es t, el historial tiene el siguiente aspecto:

  *--*--*--*--*--*       refs/wip/index/refs/heads/master
 /     /     /
A-----B-----C            refs/heads/master

Cuando magit-wip-merge-branch es nil, la creación de una confirmación en la rama real y luego hacer un cambio hace que las referencias wip sean recreadas para bifurcarse desde la nueva confirmación. Pero las confirmaciones antiguas en las wip refs no se pierden. Siguen estando disponibles en el reflog. Para que sea más fácil ver cuándo se ha cambiado el punto de bifurcación de una wip ref, se crea una confirmación adicional con el mensaje "restart autosaving" (las confirmaciones xxO de abajo son este tipo de confirmaciones).

Comenzando por:

      BI0---BI1    refs/wip/index/refs/heads/master
     /
A---B              refs/heads/master
     \
      BW0---BW1    refs/wip/wtree/refs/heads/master

y confirmando los cambios por etapas y editando y guardando un archivo resultaría en:

      BI0---BI1        refs/wip/index/refs/heads/master
     /
A---B---C              refs/heads/master
     \   \
      \   CW0---CW1    refs/wip/wtree/refs/heads/master
       \
        BW0---BW1      refs/wip/wtree/refs/heads/master@{2}

El punto de bifurcación del índice wip ref no se cambia hasta que algún cambio está siendo puesto en escena. De la misma forma, el hecho de comprobar una rama o crear una confirmación no cambia el punto de bifurcación de la wip ref del árbol de trabajo. Los puntos de bifurcación no se ajustan hasta que realmente hay un cambio que debe ser confirmado en la respectiva wip ref.

Modos de limpieza heredados

Se recomienda usar el modo magit-wip-mode e ignorar la existencia de los siguientes modos, que se conservan por razones históricas.

Establecer las siguientes variables directamente no tiene efecto; use la interfaz personalizada para hacerlo o llame a las respectivas funciones de modo.

Opción de Usuario: magi-wip-after-save-mode

Cuando este modo está habilitado, guardar un buffer que visita un archivo rastreado en un repositorio Git provoca que su estado actual sea enviado al árbol de trabajo wip ref para la rama actual.

Opción de Usuario: magit-wip-after-apply-mode

Cuando este modo está habilitado, la aplicación de un cambio a un archivo rastreado en un repositorio Git (es decir, su inclusión en área de preparación o (staging), sacar dicho archivo del área de preparación (unstaging), descartar, revertir, y aplicar regularmente los cambios a dicho archivo) hace que su estado actual sea enviado al índice y / o árbol de trabajo wip refs para la rama actual.

Si sólo se editan archivos usando Emacs y sólo se interactúa con Git usando Magit, entonces los dos modos anteriores deberían ser suficientes para proteger todos y cada uno de los cambios de pérdidas accidentales. En la práctica, nadie hace eso. Existen dos modos adicionales que hacen confirmación a los wip refs antes de hacer cambios que podrían causar la pérdida de cambios anteriores.

Opción de Usuario: magit-wip-before-change-mode

Cuando este modo está activado, ciertos comandos confirman los cambios existentes en los archivos a los que van a realizar cambios.

Opción de Usuario: magit-wip-initial-backup-mode

Cuando se activa este modo, la versión actual de un archivo se guarda en el árbol de trabajo wip ref antes de que el búfer que visita ese archivo se guarde por primera vez desde que se creó el búfer.

De este modo, se realiza una copia de seguridad de la misma versión del archivo que guardaría backup-buffer. Mientras que backup-buffer usa un archivo de copia de seguridad, este modo usa el mismo worktree wip ref que usan los otros modos de Magit Wip. Al igual que backup-buffer, sólo lo hace una vez; a menos que mate el buffer y vuelva a visitar el archivo, sólo se creará una copia de seguridad por sesión de Emacs.

Este modo ignora las variables que afectan a backup-buffer y puede usarse junto a esa función, lo cual es recomendable porque sólo hace copias de seguridad de los archivos que se rastrean en un repositorio Git.

Opción de Usuario: magit-wip-after-save-local-mode-lighter

Modo de línea para magit-wip-after-save-local-mode.

Opción de Usuario: magit-wip-after-apply-mode-lighter

Modo de línea para magit-wip-after-apply-mode

Opción de Usuario: magit-wip-before-change-mode-lighter

Modo de línea para magit-wip-before-change-mode.

Opción de Usuario: magit-wip-initial-backup-mode-lighter

Modo de línea para magit-wip-initial-backup-mode.

Comandos para búferes que visitan archivos

Por defecto, Magit define unas pocas combinaciones globales de teclas. Estos enlaces son un compromiso entre no proporcionar ningún enlace y proporcionar los mejores enlaces que me hubiera gustado usar en su lugar. Magit no puede proporcionar el conjunto de combinaciones recomendadas por defecto porque esas secuencias de teclas están estrictamente reservadas para combinaciones añadidas por el usuario. Vea también Global Bindings y (elisp)Key Binding Conventions.

Para usar los bindings recomendados, añada esto a su fichero init y reinicie Emacs:

(setq magit-define-global-key-bindings 'recommended)

Si no desea que Magit añada ningún enlace al mapa de teclado global, añada esto a su archivo init y reinicie Emacs:

(setq magit-define-global-key-bindings nil)

Ctrl-c f (C-c f, magit-file-dispatch)
Ctrl-c fs (C-c f s, magit-stage-file)
Ctrl-c fs (C-c f s, magit-stage-buffer-file)
Ctrl-c fu (C-c f u, magit-unstage-file)
Ctrl-c fu (C-c f u, magit-unstage-buffer-file)
Ctrl-c f,x (C-c f , x, magit-file-untrack)
Ctrl-c f,r (C-c f , r, magit-file-rename)
Ctrl-c f,k (C-c f , k, magit-file-delete)
Ctrl-c f,c (C-c f , c, magit-file-checkout)
Ctrl-c fD (C-c f D, magit-diff)
Ctrl-c fd (C-c f d, magit-diff-buffer-file)
Ctrl-c fL (C-c f L, magit-log)
Ctrl-c fl (C-c f l, magit-log-buffer-file)
Ctrl-c ft (C-c f t, magit-log-trace-definition)
Ctrl-c fM (C-c f M, magit-log-merged)
Ctrl-c fB (C-c f B, magit-blame)
Ctrl-c fb (C-c f b, magit-blame-additions)
Ctrl-c fr (C-c f r, magit-blame-removal)
Ctrl-c ff (C-c f f, magit-blame-reverse)
Ctrl-c fm (C-c f m, magit-blame-echo)
Ctrl-c fq (C-c f q, magit-blame-quit)
Ctrl-c fp (C-c f p, magit-blob-previous)
Ctrl-c fn (C-c f n, magit-blob-next)
Ctrl-c fv (C-c f v, magit-find-file)
Ctrl-c fV (C-c f V, magit-blob-visit-file)
Ctrl-c fg (C-c f g, magit-status-here)
Ctrl-c fG (C-c f G, magit-display-repository-buffer)
Ctrl-c fc (C-c f c, magit-commit)
Ctrl-c fe (C-c f e, magit-edit-line-commit)

Cada uno de estos comandos se documenta individualmente más abajo, junto con sus combinaciones de teclas por defecto. Las combinaciones mostradas arriba son las recomendadas, que puede activar siguiendo las instrucciones que se leen a continuación.

Ctrl-c Alt-g (C-c M-g, magit-file-dispatch)

Este comando de prefijo transitorio enlaza los siguientes comandos de sufijo y los muestra en un búfer temporal hasta que se invoque un sufijo.

Ctrl-c Alt-g s (C-c M-g s, magit-stage-file)
Ctrl-c Alt-g u (C-c M-g u, magit-unstage-buffer-file)

Deshace todos los cambios del archivo que se está visitando en el búfer actual. Cuando no se visita un archivo, se usa el primer comando, que solicita uno.

Ctrl-c Alt-g ,x (C-c M-g , x, magit-file-untrack)

Este comando deshace el seguimiento de un archivo leído por el usuario, por defecto en el archivo visitado.

Ctrl-c Alt-g ,r (C-c M-g , r, magit-file-rename)

Este comando renombra un archivo leído del usuario, por defecto el archivo visitado.

Ctrl-c Alt-g ,k (C-c M-g , k, magit-file-delete)

Este comando borra un archivo leído por el usuario, por defecto el archivo visitado.

Ctrl-c Alt-g ,c (C-c M-g , c, magit-file-checkout)

Este comando actualiza un fichero en el árbol de trabajo y el índice a los contenidos de una revisión. Tanto la revisión como el fichero son leídos por el usuario.

Ctrl-c Alt-g D (C-c M-g D, magit-diff)

Este comando de prefijo transitorio une varios comandos de sufijo diff y argumentos infix y los muestra en un búfer temporal hasta que se invoque un sufijo. Véase Difusión.

Este es el mismo comando al que se vincula d en los búferes de Magit. Si este comando se invoca desde un búfer que visita un archivo, el valor inicial de la opción (--) que limita el diff a determinado(s) archivo(s) se establece en el archivo visitado.

Ctrl-c Alt-g d (C-c M-g d, magit-diff-buffer-file)

Este comando muestra el diff para el archivo de blob que visita el buffer actual.

Opción de Usuario: magit-diff-buffer-file-locked.

Esta opción controla si magit-diff-buffer-file utiliza un buffer dedicado. Vea Modos y Búferes

Ctrl-c Alt-g L (C-c M-g L, magit-log)

Este comando de prefijo transitorio une varios comandos de sufijo de registro y argumentos de infijo y los muestra en un búfer temporal hasta que se invoque un sufijo. Véase Registros.

Se trata del mismo comando al que se vincula l en los búferes de Magit. Si este comando se invoca desde una memoria intermedia que visita un archivo, el valor inicial de la opción (--) que limita el registro a determinados archivos se establece en el archivo visitado.

Ctrl-c Alt-g l (C-c M-g l, magit-log-buffer-file)

Este comando muestra el registro del archivo o blob que visita el búfer actual. Los renombramientos se siguen cuando se usa un argumento de prefijo o cuando --follow es un argumento de registro activo. Cuando la región está activa, el registro se restringe al intervalo de líneas seleccionado.

Opción de Usuario: magit-log-buffer-file-locked

Esta opción controla si magit-log-buffer-file utiliza un búfer dedicado. Consulte Modos y Búferes.

Ctrl-c Alt-g t (C-c M-g t)

Este comando muestra el registro de la definición en el punto.

Ctrl-c Alt-g M (C-c M-g M, magit-log-merged)

Este comando lee una confirmación y una rama y muestra un registro de la fusión de la primera en la segunda. Muestra múltiples confirmaciones incluso en el caso de una fusión rápida.

Ctrl-c Alt-g B (C-c M-g B, magit-blame)

Este comando de prefijo transitorio enlaza todos los comandos de sufijo de notas (blaming) junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo.

Para obtener más información sobre este comando y los siguientes, consulte Blaming.

Además del subtransitorio magit-blame, el transitorio de envío también vincula varios comandos de sufijo de notas directamente. Consulte Blaming para obtener información sobre estos comandos y sus vínculos.

Ctrl-c Alt-g p (C-c M-g p, magit-blob-previous)

Este comando visita el blob anterior que modificó el archivo actual.

Ctrl-c Alt-g n (C-c M-g n, magit-blob-next)

Este comando visita el siguiente blob que modificó el archivo actual.

Ctrl-c Alt-g v (C-c M-g v, magit-find-file)

Este comando lee una revisión y un archivo y visita el blob correspondiente.

Ctrl-c Atl-g V (C-c M-g V, magit-blob-visit-file)

Este comando visita el fichero del árbol de trabajo, correspondiente al blob actual. Cuando se visita un blob o la versión desde el índice, entonces se va a la misma ubicación del archivo respectivo en el árbol de trabajo.

Ctrl-c Alt-g g (C-c M-g g, magit-status-here)

Este comando muestra el estado del repositorio actual en un buffer, como hace magit-status. Además, intenta ir a la posición en ese búfer, que corresponde a la posición en el búfer de visita del archivo actual (si existe).

Ctrl-c Alt-g G (C-c M-g G, magit-display-repository-buffer)

Este comando lee y muestra un buffer Magit perteneciente al repositorio actual, sin refrescarlo.

Ctrl-c Alt-g c (C-c M-g c, magit-commit)

Este comando de prefijo transitorio vincula los siguientes comandos de sufijo junto con los argumentos de infijo apropiados y los muestra en un búfer temporal hasta que se invoque un sufijo. Véase Iniciando una Confirmación.

Ctrl-c Alt-g e (C-c M-g e, magit-edit-line-commit)

Este comando hace editable la confirmación que añadió la línea actual.

Con un prefijo como argumento, hace editable la confirmación que elimina la línea, si existe. La confirmación se determina usando git blame y se hace editable usando git rebase --interactive si es accesible desde HEAD, o comprobando la confirmación (o una rama que apunte a ella) en caso contrario.

Modo menor para búferes que visitan blobs

El modo magit-blob habilita ciertas características de Magit en los buffers que visitan blobs. Dichos buffers pueden crearse utilizando magit-find-file y algunos de los comandos mencionados a continuación, que también se encargan de activar este modo menor. Actualmente este modo sólo establece unos pocos enlaces de teclas, pero podría ampliarse.

p (p, magit-blob-previous)

Visita el blob anterior que modificó el archivo actual.

n (n, magit-blob-next)

Visita el siguiente blob que modificó el archivo actual.

q (q, magit-kill-this-buffer)

Elimina el búfer actual.

Personalización

Tanto Git como Emacs son altamente personalizables. Magit es tanto una porcelana de Git como un paquete de Emacs, así que tiene sentido personalizarlo usando tanto variables de Git como opciones de Emacs. Sin embargo esta flexibilidad no viene sin problemas, incluyendo pero no limitándose a los siguientes.

• Algunas variables Git tienen automáticamente un efecto en Magit sin requerir ningún soporte explícito. A veces eso es deseable - en otros casos, rompe Magit.
  
  Cuando una determinada configuración de Git rompe Magit pero se quiere seguir usando esa configuración en la línea de comandos, entonces se puede lograr anulando el valor sólo para Magit añadiendo algo como ("-c" "some.variable=compatible-value") a magit-git-global-arguments.
• Ciertos ajustes como fetch.prune=true son respetados por los comandos Magit (porque simplemente llaman al respectivo comando Git) pero su valor no se refleja en los respectivos buffers transitorios. En este caso, el argumento --prune en magit-fetch puede estar activo o inactivo, pero eso no impide que la variable Git sea respetada por los comandos sufijo de todos modos. Por lo tanto, el corte puede ocurrir a pesar de que los argumentos --prune se muestren de una manera que parezca indicar que no ocurrirá ningún corte.

Tengo la intención de abordar estas cuestiones y otras similares en una de las próximas versiones.

Configuración por repositorio

Magit puede configurarse a nivel de repositorio usando tanto variables Git como opciones Emacs.

Para establecer una variable Git sólo para un repositorio, simplemente establécela en /ruta/al/repositorio/.git/config en lugar de $HOME/.gitconfig o /etc/gitconfig. Ver la página de manual de git-config(1).

De forma similar, las opciones de Emacs pueden establecerse sólo para un repositorio editando /ruta/al/repo/.dir-locals.el. Ver (emacs)Variables de directorio. Por ejemplo, para desactivar los refrescos automáticos de los buffers de visita de ficheros en un único repositorio, use esto:

/ruta/al/repo/.dir-locals.el
((nil . ((magit-refresh-buffers . nil))))

Puede que sólo sea costoso insertar cierta información en los buffers Magit para repositorios que son excepcionalmente grandes, en cuyo caso puede desactivar los inserctores de sección respectivos sólo para ese repositorio:

/ruta/a/etiqueta/invertida/repo/.dir-locals.el
((magit-status-mode
  . ((eval . (magit-disable-section-inserter 'magit-insert-tags-header)))))

Función: magit-disable-section-inserter fn

Esta función desactiva el inserctor de secciones FN en el repositorio actual. Sólo está pensada para su uso en .dir-locals.el y .dir-locals-2.el.

Si desea aplicar la misma configuración a varios repositorios, pero no a todos, entonces mantener sincronizados los archivos de configuración locales de los repositorios se convertiría rápidamente en una molestia. Para evitarlo, puede crear ficheros de configuración para ciertas clases de repositorios (por ejemplo, "repositorios enormes") y luego incluir esos ficheros en los ficheros de configuración por repositorio. Por ejemplo:

• /ruta/al/enorme/repo/.git/config
  [include]
          path = /path/to/huge-gitconfig
  	

• /ruta/al/enorme-gitconfig
  [status]
          showUntrackedFiles = no
  	

• $HOME/.emacs.d/init.el
  (dir-locals-set-class-variables 'huge-git-repository
     '((nil . ((magit-refresh-buffers . nil)))))
  
  (dir-locals-set-directory-class
     "/ruta/al/enorme/repo/" 'huge-git-repository)
  	

Configuraciones Esenciales

En las tres secciones siguientes se enumeran y analizan diversas variables que muchos Usuarios podrían querer personalizar, por motivos de seguridad y/o rendimiento.

Seguridad

Esta sección discute varias variables que podría querer cambiar (o no cambiar) por razones de seguridad.

Git mantiene los cambios confirmados el tiempo suficiente para que los Usuarios puedan recuperar los cambios que han sido borrados accidentalmente. No hace lo mismo con los cambios no confirmados en el árbol de trabajo y ni siquiera en el índice (el área de preparación). Debido a que Magit hace que sea tan fácil modificar cambios no confirmados, también hace que sea fácil dispararse en el pie en el proceso. Por esa razón, Magit proporciona tres modos globales que guardan los archivos rastreados en referencias de trabajo en curso después o antes de ciertas acciones. Ver Modos de borrado.

Estos modos no están activados por defecto por cuestiones de rendimiento. En cambio, muchos comandos potencialmente destructivos requieren confirmación cada vez que se usan. En muchos casos esto puede desactivarse añadiendo un símbolo a magit-no-confirm (ver Finalización y confirmación). Si activa los distintos modos wip, debería añadir safe-with-wip a esta lista.

Del mismo modo, no es necesario pedir confirmación antes de mover un archivo a la papelera del sistema: si ha enviado un archivo a la papelera por error, puede recuperarlo desde allí. La opción magit-delete-by-moving-to-trash controla si se usará la papelera del sistema, que es el caso por defecto. Sin embargo, la papelera no es un elemento de magit-no-confirm, puede que quiera cambiarlo.

Por defecto, los buffers que visitan ficheros se revierten automáticamente cuando el fichero visitado cambia en el disco. Esto no es tan arriesgado como podría parecer, pero para tomar una decisión informada debería ver Riesgo de revertir automáticamente.

Rendimiento

Después de que Magit haya ejecutado git for side-effects, también refresca el buffer actual de Magit y el respectivo buffer de estado. Esto es necesario porque, de lo contrario, podría mostrarse información obsoleta sin que el usuario se diera cuenta. Los buffers Magit se actualizan recreando su contenido desde cero, lo que hace que la actualización sea más sencilla y menos propensa a errores, pero también más costosa. Mantener la simplicidad y recrear todo desde cero es una vieja decisión de diseño y apartarse de ella requerirá una refactorización importante.

Planeo hacerlo a tiempo para la próxima gran versión. También tengo la intención de crear logs y diffs de forma asíncrona, lo que también debería ayudar mucho, pero también requiere una refactorización importante.

Mientras tanto, puede decirle a Magit que sólo actualice automáticamente el búfer actual de Magit, pero no el búfer de estado. Si hace eso, el búfer de estado sólo se actualizará automáticamente si es el búfer actual.

(setq magit-refresh-status-buffer nil)

Debería comprobar si algún paquete de terceros ha añadido algo a magit-refresh-buffer-hook, magit-status-refresh-hook, magit-pre-refresh-hook y magit-post-refresh-hook. Si es así, compruebe si esas adiciones afectan significativamente al rendimiento.

A Magit se le puede indicar que refresque los buffers de forma verbosa usando Alt-x magit-toggle-verbose-refresh (M-x magit-toggle-verbose-refresh) Activar esta opción ayuda a averiguar qué secciones son cuellos de botella. La salida adicional se encuentra en el búfer *Messages*.

Magit también revierte buffers para archivos visitados localizados dentro del repositorio actual cuando el archivo visitado cambia en disco. Esto se implementa sobre el modo auto-revert de la librería integrada autorevert. Para averiguar si esto afecta al rendimiento, compruebe si el rendimiento es significativamente peor, cuando existen muchos buffers y/o cuando algunos buffers visitan ficheros usando TRAMP. Si es así, entonces esto debería ayudar.

(setq auto-revert-buffer-list-filter
      'magit-auto-revert-repository-buffer-p)

Para enfoques alternativos, consulte Reversión automática de búferes que visitan archivos.

Si ha activado alguna función que está desactivada por defecto, debería comprobar si afecta al rendimiento de forma significativa. Es probable que no estuvieran habilitadas por defecto porque se sabe que reducen el rendimiento al menos en repositorios grandes.

Si el rendimiento sólo es lento dentro de ciertos repositorios inusualmente grandes, puede que quiera deshabilitar ciertas características sólo por repositorio o por clase de repositorio. Vea Configuración por repositorio. Por ejemplo, lleva mucho tiempo determinar la etiqueta siguiente y la actual en repositorios con un número excepcional de etiquetas. Por lo tanto, sería una buena idea deshabilitar magit-insert-tags-headers, como se explica en el nodo mencionado.

Rendimiento de los registros

Al mostrar logs, Magit limita el número de confirmaciones mostradas inicialmente con la esperanza de que esto evite trabajo innecesario. Cuando se usa --graph, desafortunadamente esto no tiene el efecto deseado para historiales grandes. Junio, el mantenedor de Git, dijo en la lista de correo de git (https://www.spinics.net/lists/git/msg232230.html): "--graph quiere calcular todo el historial y el max-count sólo afecta a la fase de salida después de que --graph haga su cálculo".

En otras palabras, no es que Git sea lento a la hora de mostrar las diferencias, o que Magit sea lento a la hora de analizar la salida - el problema es que Git primero sale a fumar.

De hecho, solucionamos este problema limitando el número de confirmaciones no sólo mediante -<N>, sino también usando un rango. Pero desafortunadamente esto no siempre es posible.

Cuando se muestran más de unos pocos miles de confirmaciones, el uso de --graph puede ralentizar las cosas.

Usar --color --graph es incluso más lento. Magit usa código que es parte de Emacs para convertir caracteres de control en caras. Ese código es bastante lento y esto se nota bastante cuando se muestra un log con muchas ramas y fusiones. Por esta razón --color ya no está activado por defecto. Considere dejarlo así.

Rendimiento de los Diff

Si los diffs son lentos, entonces considere desactivar algunas características opcionales referidas a ellos estableciendo todas o algunas de las siguientes variables a nil: magit-diff-highlight-indentation, magit-diff-highlight-trailing, magit-diff-paint-whitespace, magit-diff-highlight-hunk-body, y magit-diff-refine-hunk.

Cuando se muestra una confirmación en lugar de un diff arbitrario, se muestra información adicional. Calcular esta información puede ser bastante costoso dadas ciertas circunstancias. Si mirar una confirmación usando el modo magit-revision lleva considerablemente más tiempo que mirar la misma confirmación en el modo magit-diff, considere establecer magit-revision-insert-related-refs a nil.

Si se encuentra a menudo con diffs que contienen ficheros borrados, puede activar el argumento --irreversible-delete. Si lo hace, los diffs seguirán mostrando que un fichero ha sido borrado, pero sin mostrar también todo el contenido borrado del fichero. Este argumento no está disponible por defecto, vea Activación y desactivación (transitoria) de sufijos. Una vez que lo haya hecho debería habilitarlo y guardar esa configuración, vea (transitorio)Guardar valores. Debería hacer esto tanto en la ventana emergente diff (d) como en la ventana emergente diff refresh (D).

Rendimiento del búfer de referencia (Refs)

Cuando la actualización del "búfer de referencias" es lenta, suele deberse a que se están mostrando varios cientos de referencias. La mejor manera de solucionar esto es mostrar menos referencias, obviamente.

Si no le interesa ver la lista de etiquetas, o le interesa muy poco, empiece por no mostrarlas:

(remove-hook 'magit-refs-sections-hook 'magit-insert-tags)

A continuación, asegúrese de que todas las ramas remotas de la lista existen realmente. Para ello, elimine las ramas que ya no existan con f-pa.

Rendimiento de las confirmaciones

Cuando inicia una confirmación, Magit por defecto muestra automáticamente un diff de los cambios que está a punto de confirmar. Para confirmaciones grandes esto puede llevar mucho tiempo, lo que es especialmente molesto cuando está confirmando grandes cantidades de datos generados que en realidad no tiene intención de inspeccionar antes de confirmar. Este comportamiento puede desactivarse usando:

(remove-hook 'server-switch-hook 'magit-commit-diff)
(remove-hook 'with-editor-filter-visit-hook 'magit-commit-diff)

A continuación, puede escribir Ctrl-c Ctrl-d (C-c C-d) para mostrar el diff cuando realmente quiera verlo, pero sólo entonces. Alternativamente, puede dejar el gancho y simplemente teclear Ctrl-g (C-g) en aquellos casos en los que se tarde demasiado en generar el diff. Si hace eso, acabará con un búfer de diferencias roto, pero hacerlo de esta forma tiene la ventaja de que normalmente puede ver la diferencia, lo que es útil porque aumenta las probabilidades de que detecte problemas potenciales.

Rendimiento de Microsoft Window

Para actualizar el búfer de estado, git tiene que ejecutarse unas cuantas docenas de veces. Esto es problemático en Microsoft Windows, porque el sistema operativo es excepcionalmente lento a la hora de iniciar procesos. Lamentablemente, este es un problema que sólo puede ser solucionado por el propio Microsoft, y no parecen estar particularmente interesados en hacerlo.

Además del problema de los subprocesos, existen otros problemas de rendimiento específicos de Windows. Algunos de ellos tienen solución. Los mantenedores de "Git para Windows" intentan mejorar el rendimiento en Windows. Utiliza siempre la última versión para beneficiarte de los últimos ajustes de rendimiento. Magit también intenta solucionar algunos problemas específicos de Windows.

Según algunas fuentes, configurar las siguientes variables de Git también puede ayudar.

git config --global core.preloadindex true   # default since v2.1
git config --global core.fscache true        # default since v2.8
git config --global gc.auto 256

También debería comprobar si un programa antivirus está afectando al rendimiento.

Rendimiento MacOS

Antes de Emacs 26.1 los procesos hijo se creaban usando fork en macOS. Esto copiaba innecesariamente recursos GUI, lo cual es costoso. El resultado era que la bifurcación tardaba unas 30 veces más en Darwin que en Linux, y como Magit inicia muchos procesos git eso marcaba bastante la diferencia.

Así que asegúrese de que está usando al menos Emacs 26.1, en cuyo caso se usará el vfork más rápido. (La creación de procesos hijo sigue tardando el doble en Darwin que en Linux). Vea aquí para más información.

Además, git instalado desde un gestor de paquetes como brew o nix parece ser más lento que el ejecutable nativo. Compare el ejecutable de git que está corrientdo con el que está en /usr/bin/git, y si nota una diferencia notable intente usar este último como magit-git-executable.

Atajos de teclado Globales

Opción de Usuario: magit-define-global-key-bindings

Esta opción controla qué conjunto de combinaciones de teclas de Magit, si las hay, pueden añadirse al mapa de teclas global, incluso antes de que Magit se utilice por primera vez en la sesión actual de Emacs.

• Si el valor es nil, no se añade ningún enlace.
• Si es por defecto (default), quizá añadir:
  C-x g magit-status
  C-x M-g magit-dispatch
  C-c M-g magit-file-dispatch
• Si es recomendado (recommended), quizá añadir:
  C-x g magit-status
  C-c g magit-dispatch
  C-c f magit-file-dispatch
  
  Estos enlaces son muy recomendables, pero no podemos usarlos por defecto, porque el espacio de nombres C-c <LETTER> está estrictamente reservado para enlaces añadidos por el usuario (ver (elisp)Convenciones de enlace de claves).

Las vinculaciones del conjunto elegido pueden añadirse cuando se ejecuta after-init-hook. Cada vinculación se añade si, y sólo si, en ese momento ninguna otra tecla está vinculada al mismo comando, y ningún otro comando está vinculado a la misma tecla. En otras palabras, intentamos evitar añadir vinculaciones innecesarias, así como vinculaciones que entren en conflicto con otras vinculaciones.

La adición de estos enlaces se retrasa hasta después de que se ejecute init-hook para permitir a los usuarios establecer la variable en cualquier parte de su archivo init (sin tener que asegurarse de hacerlo antes de que magit se cargue o autocargue) y para aumentar la probabilidad de que todos los enlaces de usuario potencialmente conflictivos ya se hayan añadido.

Para establecer esta variable use setq o la interfaz Custom. No utilice la función customize-set-variable porque esto haría que Magit se cargara inmediatamente, cuando se evalúa ese formulario (esto difiere de custom-set-variables, que no carga las librerías que definen las variables personalizadas).

Establecer esta variable no tiene efecto si ya se ha ejecutado after-init-hook.

Plumbing

Las siguientes secciones describen cómo usar varias de las abstracciones del núcleo de Magit para extender el propio Magit o implementar una extensión independiente.

Algunas de las características de bajo nivel usadas por Magit han sido divididas en bibliotecas/paquetes separados, para que puedan ser usadas por otros paquetes, sin tener que depender de Magit. Ver (with-editor)Top para información sobre with-editor. transient aún no tiene manual.

Si está intentando encontrar una clave sin usar que pueda vincular a un comando proporcionado por su propia extensión Magit, consulte https://github.com/magit/magit/wiki/Plugin-Dispatch-Key-Registry.

Llamar a Git

Magit proporciona muchas funciones especializadas para llamar a Git. Todas estas funciones están definidas en magit-git.el o magit-process.el y tienen uno de los prefijos magit-run-, magit-call-, magit-start-, o magit-git- (que también se usa para otras cosas).

Todas estas funciones aceptan un número indefinido de argumentos, que son cadenas que especifican argumentos de línea de comandos para Git (o en algunos casos un ejecutable arbitrario). Estos argumentos son aplanados antes de ser pasados al ejecutable; por lo que en lugar de cadenas también pueden ser listas de cadenas y los argumentos que son nil (nulos) se descartan silenciosamente. Algunas de estas funciones también requieren un único argumento obligatorio antes de estos argumentos de línea de comandos.

A grandes rasgos, estas funciones ejecutan Git para obtener algún valor o por efectos secundarios. Las funciones que devuelven un valor son útiles para recoger la información necesaria para rellenar un búfer Magit, mientras que las otras se usan para implementar comandos Magit.

Las funciones del grupo de sólo-valor siempre se ejecutan de forma sincrónica y nunca activan una actualización. Las funciones del grupo de efectos secundarios pueden dividirse a su vez en subgrupos dependiendo de si ejecutan Git de forma sincrónica o asincrónica, y dependiendo de si activan una actualización cuando el ejecutable ha finalizado.

Obtener un valor de Git

Estas funciones ejecutan Git para obtener un valor, un estado de salida o una salida. Por supuesto, también podría utilizarlas para ejecutar comandos Git que tienen efectos secundarios, pero eso debería evitarse.

Función: magit-git-exit-code &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve código de salida pertinente.

Función: magit-git-success &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve t si el código de salida es 0, nil en caso contrario.

Función: magit-git-failure &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve t si el código de salida es 1, nil en caso contrario.

Función: magit-git-true &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve t si la primera línea impresa por git es la cadena "true", nil en caso contrario.

Función: magit-git-false &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve t si la primera línea impresa por git es la cadena "false", nil en caso contrario.

Función: magit-git-insert &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS e inserta su salida en el punto.

Función: magit-git-string &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve la primera línea de su salida. Si no hay salida o si comienza con un carácter de nueva línea, devuelve nil.

Función: magit-git-lines &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve su salida como una lista de líneas. Las líneas vacías en cualquier parte de la salida se omiten.

Función: magit-git-lines &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve su salida como una lista de líneas. Las líneas vacías en cualquier parte de la salida se omiten.

Función: magit-git-items &resto de ARGUMENTOS

Ejecuta git con ARGUMENTOS y devuelve su salida separada por nulos como una lista. Los elementos vacíos en cualquier parte de la salida se omiten.

Si el valor de la opción magit-git-debug es distinto de cero y git sale con un estado de salida distinto de cero, advierte de ello en el área de eco y añade una sección conteniendo el error estándar de git en el buffer de proceso del repositorio actual.

Función: magit-process-git DESTINO &resto de ARGUMENTOS

Llama a Git sincrónicamente en un proceso separado, devolviendo su código de salida. DESTINO especifica como manejar la salida, como para call-process, excepto que los manejadores de archivos son soportados. Activa la opción "noglob" de Cygwin durante la llamada y asegura la conversión eol de unix.

Función: magit-process-file procesos & visualización opcional del búfer de entrada &resto de ARGUMENTOS

Procesa archivos de forma sincrónica en un proceso separado. Idéntico a process-file pero habilita temporalmente la opción "noglob" de Cygwin durante la llamada y asegura la conversión eol de unix.

Si se produce un fallo al usar una de las funciones anteriores, suele deberse a un error -posiblemente- en la escritura, es decir, al uso de un argumento que en realidad no está soportado. Estos errores no se suelen notificar, pero cuando se producen debemos ser capaces de depurarlos.

Función de Usuario: magit-git-debug

Si se informa de los errores que ocurren al usar magit-git-insert, magit-git-string, magit-git-lines, o magit-git-items. Esto no genera un error. En su lugar, se muestra un mensaje en el área de eco, y el error estándar de git se inserta en una nueva sección en el buffer de proceso del repositorio actual.

Función: magit-git-str & resto de ARGUMENTOS

Esta es una variante de magit-git-string que ignora la opción magit-git-debug. Está pensada principalmente para ser usada mientras se manejan errores en funciones que sí respetan esa opción. Usar una función de este tipo mientras se maneja un error podría causar otro error más y, por tanto, llevar a una recursión infinita. Probablemente nunca necesitará usar esta función.

Llamar a Git para que surta efecto

Estas funciones se usan para ejecutar git y producir algún efecto. La mayoría de los comandos Magit que realmente ejecutan git lo hacen usando una función de este tipo.

Como no necesitamos consumir la salida de git cuando usamos estas funciones, su salida se registra en un buffer por repositorio, que puede mostrarse usando $ desde un buffer Magit o M-x magit-process en otro lugar.

Estas funciones pueden tener efecto de dos formas distintas. En primer lugar, ejecutar git puede cambiar algo, es decir, crear o empujar una nueva confirmación. En segundo lugar, ese cambio puede requerir que los buffers de Magit se refresquen para reflejar el cambio de estado del repositorio. Pero refrescar no siempre es deseable, así que sólo algunas de estas funciones realizan tal refresco después de que git haya vuelto.

A veces es útil ejecutar git de forma asíncrona. Por ejemplo, cuando el Usuario acaba de iniciar un push, entonces no hay razón para hacerle esperar hasta que se haya completado. En otros casos tiene sentido esperar a que git se complete antes de dejar que el usuario haga otra cosa. Por ejemplo, después de poner en escena un cambio, es útil esperar hasta después de la actualización, ya que también se mueve automáticamente al siguiente cambio.

Función: magit-call-git &resto de ARGUMENTOS

Llama a git de forma sincrónica con ARGUMENTOS.

Función: magit-call-process PROGRAMA &resto de ARGUMENTOS

Llama a PROGRAMA de forma sincrónica con ARGUMENTOS.

Función: magit-run-git- &resto de ARGUMENTOS

Llama a git de forma sincrónica con ARGUMENTOS y luego se actualiza.

Función: magit-run-git-with-input &resto de ARGUMENTOS

Llama a git sincrónicamente con ARGUMENTOS y envía el contenido del buffer actual a la entrada estándar.

Si el directorio por defecto del buffer actual está en un sistema de archivos remoto, esta función en realidad ejecuta git de forma asíncrona. No obstante, espera a que el proceso regrese, por lo que la función en sí es sincrónica.

Función: magit-git &resto de ARGUMENTOS

Llama a git sincrónicamente con ARGUMENTOS sólo para efectos secundarios. Esta función no actualiza el búfer.

Función: magit-git-wash lavadora &resto de ARGUMENTOS

Ejecuta Git con ARGUMENTOS, insertando la salida limpia (lavada) en el punto. En realidad primero inserta esta salida en el punto. Si no hay salida llama a magit-cancel-section. Si no, reduce temporalmente el buffer al texto insertado, sitúese al principio y llame a la función LAVADORA con ARGUMENTOS como único argumento.

Y ahora las variantes asíncronas.

Función: magit-run-git-async &resto de ARGUMENTOS

Inicia Git, prepara la actualización y devuelve el objeto de proceso. ARGUMENTOS se aplana y luego se usa como argumentos para Git.

Muestra los argumentos de la línea de comandos en el área de eco.

Tras el retorno de Git se refrescan algunos buffers: el buffer que estaba activo cuando se llamó a esta función (si es un buffer Magit y sigue vivo), así como el respectivo buffer de estado Magit. Los búferes no modificados que visitan archivos que son rastreados en el repositorio actual son revertidos si magit-revert-buffers es distinto de nil.

Función: magit-run-git-with-editor &resto de ARGUMENTOS

Exporta GIT_EDITOR e inicia Git. También prepara para refrescar y devuelve el objeto de proceso. ARGUMENTOS se aplana y luego se utiliza como argumentos para Git.

Muestra los argumentos de la línea de comandos en el área de eco.

Tras el retorno de Git se refrescan algunos buffers: el buffer que estaba activo cuando se llamó a esta función (si es un buffer Magit y sigue vivo), así como el respectivo buffer de estado Magit.

Función: magit-start-git entrada &resto de ARGUMENTOS

Inicia Git, prepara la actualización y devuelve el objeto del proceso.

Si entrada no es nulo, tiene que ser un buffer o el nombre de un buffer existente. El contenido del búfer se convierte en la entrada estándar del proceso.

La opción magit-git-executable especifica el ejecutable de Git y la opción magit-git-global-arguments especifica argumentos constantes. Los argumentos restantes ARGUMENTOS especifican argumentos para Git. Se aplanan antes de su uso.

Después de que Git responda, algunos búferes se actualizan: el búfer que estaba activo cuando se llamó a esta función (si es un búfer Magit y sigue activo), así como el búfer de estado Magit correspondiente. Los búferes no modificados que visitan archivos que son rastreados en el repositorio actual son revertidos si magit-revert-buffers es distinto de nil.

Función: magit-start-process entrada &resto de ARGUMENTOS

Inicia PROGRAMA (o proceso), prepara para refrescar, y devuelve el objeto de proceso.

Si el argumento opcional ENTRADA no es nulo, tiene que ser un buffer o el nombre de un buffer existente. El contenido del buffer se convierte en la entrada estándar del proceso.

El proceso se inicia usando start-file-process y luego se configura para usar el centinela magit-process-sentinel y el filtro magit-process-filter. La información requerida por estas funciones se almacena en el objeto proceso. Cuando esta función regresa, el proceso aún no ha comenzado a ejecutarse, por lo que es posible anular el centinela y el filtro.

Cuando el proceso regresa, magit-process-sentinel actualiza el búfer que estaba activo cuando se llamó a magit-start-process (si es un búfer Magit y sigue vivo), así como el búfer de estado Magit correspondiente. Los búferes no modificados que visitan archivos que son rastreados en el repositorio actual son revertidos si magit-revert-buffers es distinto de nil.

Variable: magit-this-process

El proceso hijo que está a punto de iniciarse. Puede utilizarse para cambiar el filtro y el centinela.

Variable: magit-process-raise-error

Cuando es distinto de nil, magit-process-sentinel genera un error si git sale con un estado de salida distinto de cero. Para propósitos de depuración.

Sección Plumbing

Creación de Secciones

Función: magit-insert-section &resto de ARGUMENTOS

Inserta una sección en el punto.

TYPE es el tipo de sección, un símbolo. Muchos comandos que actúan sobre la sección actual se comportan de forma diferente dependiendo de ese tipo. Además, si existe una variable magit-TYPE-section-map, se usa como el mapa de teclado de todas las propiedades de texto pertenecientes a la sección (pero esto puede sobrescribirse en las subsecciones). TYPE también puede tener la forma (eval FORM) en cuyo caso FORM evalúa en tiempo de ejecución.

VALUE (VALOR, es opcional) es el valor de la sección, normalmente una cadena que se requiere cuando se actúa sobre la sección.

Cuando HIDE (OCULTO, es opcional) es distinto de nil, colapsa el cuerpo de la sección por defecto, es decir, cuando se crea la sección por primera vez, pero no cuando se refresca el buffer. En caso contrario, se expande por defecto. Esto puede sobrescribirse utilizando magit-section-set-visibility-hook. Cuando se vuelve a crear una sección durante una actualización, se hereda la visibilidad del predecesor y se ignora HIDE (pero se sigue respetando el gancho).

BODY (CUERPO) es cualquier número de formularios que realmente insertan el encabezado y el cuerpo de la sección. NAME (NOMBRE, opcional), si se especifica, tiene que ser un símbolo, que luego se vincula a la estructura de la sección que se inserta.

Antes de que se evalúe BODY el inicio del objeto sección se establece en el valor de punto y después de que se evalúe BODY su final se establece en el nuevo valor de punto; BODY es responsable de mover el punto hacia adelante.

Si dentro de BODY resulta que la sección está vacía, entonces se puede usar magit-cancel-section para abortar y eliminar todo rastro de la sección parcialmente insertada. Esto puede ocurrir cuando se crea una sección limpiando la salida de Git y Git en realidad no ha sacado nada esta vez.

Función: magit-insert-heading &resto de ARGUMENTOS

Inserta el encabezado de la sección que se está insertando actualmente.

Esta función sólo debe usarse dentro de magit-insert-section.

Cuando se llama sin ARGUMENTOS, sólo establece la ranura de contenido del objeto (content) que representa la sección que se está insertando en un marcador en el punto. La sección sólo debe contener una única línea cuando esta función se usa así.

Cuando se llama con ARUGMENTOS, que tienen que ser cadenas, entonces inserta esas cadenas en el punto. La sección no debe contener ningún texto antes de que esto ocurra y después debe contener sólo una línea. Si la propiedad face se establece en cualquier lugar dentro de cualquiera de estas cadenas, entonces insértalas todas sin cambios. De lo contrario, usa la cara magit-section-heading para todo el texto insertado.

La propiedad content de la estructura de sección es el final del encabezado (que dura de start hasta content (desde el inicio hasta el contenido)) y el principio del cuerpo (que dura desde content hasta end (desde el contenido hasta el final)). Si el valor de content es nil, entonces la sección no tiene encabezado y su cuerpo no se puede contraer. Si una sección tiene un encabezado, su altura debe ser exactamente de una línea, incluyendo un carácter de nueva línea al final. Esto no es obligatorio; Usted es responsable de hacerlo correctamente. La única excepción es que esta función inserta un carácter de nueva línea si es necesario.

Función: magit-cancel-section

Cancela la sección que se está insertando. Esto sale de la llamada más interna a magit-insert-section y elimina todos los rastros de lo que ya ha sucedido dentro de esa llamada.

Función: magit-define-section-jumper TÍTULO SYM & VALOR OPCIONAL

Define una función interactiva para ir a la sección SYM. TÍTULO es el título mostrado de la sección.

Selección de Sección

Función: magit-current-section

Devuelve la sección en el punto.

Función: magit-region-section & opcional MÚLTIPLE CONDICIÓN

Devuelve una lista de las secciones seleccionadas.

Cuando la región está activa y constituye una selección de sección válida, devuelve una lista de todas las secciones seleccionadas. Este es el caso cuando la región comienza en el encabezado de una sección y termina en el encabezado de la misma sección o en el de una sección hermana. Si la opción MÚLTIPLE no es nula, la región no puede comenzar y terminar en la misma sección.

Si la selección no es válida, devuelve nil. En este caso, la mayoría de los comandos que pueden actuar sobre las secciones seleccionadas actuarán en su lugar sobre la sección en el punto.

Cuando la región tiene el mismo aspecto que en cualquier otra memoria intermedia, la selección no es válida. Cuando la selección es válida entonces la región usa la cara magit-section-highlight. Esto no se aplica a los diffs, donde las cosas se complican un poco más, pero incluso aquí, si la región tiene el aspecto habitual, no es una selección válida para esta función.

Si la CONDICIÓN opcional no es nula, la selección no sólo tiene que ser válida, sino que además todas las secciones seleccionadas tienen que coincidir con la CONDICIÓN, o se devolverá nil. Consulte magit-section-match para conocer las formas que puede adoptar CONDICIÓN.

Función: magit-region-values & opcional CONDICIÓN MÚLTIPLE

Devuelve una lista de los valores de las secciones seleccionadas.

Devuelve los valores que a su vez serían devueltos por magit-region-sections (que ver).

Secciones Coincidentes

Alt-x magit-describe-section-briefly (M-x magit-describe-section-briefly)

Muestra información sobre la sección en el punto. Este comando está pensado para fines de depuración.

Función: magit-section-ident SECCIÓN

Devuelve un identificador único para SECCIÓN. El valor devuelto tiene la forma ((TIPO . VALOR)...).

Función: magit-get-section IDENTIFICACIÓN & opcional ROOT

Devuelve la sección identificada por IDENTIFICACiÓN. IDENTIFICACIÓN tiene que ser una lista como la devuelta por magit-section-ident.

Función: magit-section-match CONDICIÓN & SECCIÓN opcional

Devuelve t si SECCIÓN coincide con CONDICIÓN. SECCIÓN es por defecto la sección en el punto. Si no se especifica SECCIÓN y tampoco hay sección en el punto, devuelve nil.

• (CONDICIÓN...)
  coincide si alguna de las CONDICIONES coincide.
• [CLASS...]
  coincide si la clase de la sección es la misma que la primera CLASE o una subclase de ésta; la clase padre de la sección coincide con la segunda CLASE; y así sucesivamente.
• [* CLASS...]
  coincide con las secciones que coinciden con [CLASS...] y también recursivamente con todas sus secciones hijas.
• CLASS
  coincide si la clase de la sección es la misma que CLASS o una subclase de ésta; independientemente de las clases de las secciones padre.

Cada CLASE (CLASS) debe ser un símbolo de clase, identificando una clase que deriva de magit-section. Por compatibilidad con versiones anteriores, CLASS también puede ser un "símbolo de tipo". Una sección coincide con un símbolo de este tipo si el valor de su ranura type es eq. Si un símbolo de tipo tiene una entrada en magit--section-type-alist, entonces una sección también coincide con ese tipo si su clase es una subclase de la clase que corresponde al tipo según esa lista.

Tenga en cuenta que no es necesario especificar el linaje completo de la sección tal y como lo imprime magit-describe-section-briefly, a menos que, por supuesto, quiera ser tan preciso.

Función: magit-section-value-if CONDICIÓN & SECCIÓN opcionl

Si la SECCIÓN opcional no es nula, comprueba si coincide. Si no hay sección en el punto y SECCIÓN es nula, devuelve nil. Si la sección no coincide, también devuelve nil.

Vea magit-section-match por las formas que puede adoptar la CONDICIÓN.

Función: magit-section-case & resto de CLÁUSULAS

Elija entre las cláusulas en el tipo de la sección en el punto.

Cada CLÁUSULA tiene el aspecto siguiente (CONDICIÓN CUERPO...). El tipo de la sección se compara con cada CONDICIÓN; las formas del CUERPO de la primera coincidencia se evalúan secuencialmente y se devuelve el valor de la última forma. Dentro de CUERPO el símbolo it está ligado a la sección en el punto. Si ninguna cláusula tiene éxito o si no hay sección en el punto devuelve nil.

Véase magit-section-match para las formas que puede adoptar CONDICIÓN. Además, se permite una CONDICIÓN t en la cláusula final y coincide si ninguna otra CONDICIÓN coincide, incluso si no hay sección en el punto.

Variable: magit-root-section

La sección raíz del búfer actual. Todas las demás secciones son descendientes de esta sección. El valor de esta variable lo establece magit-insert-section y nunca debe modificarse.

Para las secciones relacionadas con diff existen algunas herramientas adicionales.

Función: magit-diff-type &SECCIÓN opcional

Devuelve el tipo diff de SECCIÓN.

El tipo devuelto es uno de los símbolos preparado (staged), sin preparar (unstaged), confirmado (committed) o sin definir (undefined). Este tipo cumple una función similar a la del tipo general común a todas las secciones (que se almacena en la ranura type de la estructura magit-section correspondiente), pero tiene en cuenta información adicional. Cuando SECCION no está relacionado con diffs y el búfer que la contiene tampoco es un búfer sólo para diffs, devuelve nil.

Actualmente el tipo también puede ser tracked o untracked (archivos rastreados o sin rastrear), pero estos valores no se manejan explícitamente en todos los lugares donde deberían. Una posible solución podría ser simplemente devolver nil aquí.

La sección tiene que ser una sección diff o hunk, o una sección cuyos hijos sean de tipo diff. Si SECCIÓN opcional es nil, devuelve el tipo diff de la sección actual. En buffers cuyo modo principal es magit-diff-mode, SECCION se ignora y el tipo se determina por otros medios. En búferes magit-revision-mode el tipo siempre se consigna.

Función: magit-diff-scope &SECCIÓN estricta

Devuelve el ámbito del diff de SECCIÓN o de la(s) sección(es) seleccionada(s).

El "ámbito" de un diff (diff's scope) describe qué parte de un diff se selecciona, es un símbolo, uno de región, hunk, hunks, file, files o list. No confunda esto con el "tipo" del diff, devuelto por magit-diff-type.

Si SECCIÓN opcional no es nulo, devuelve el ámbito de la misma, ignorando las secciones seleccionadas por la región. En caso contrario, devuelve el ámbito de la sección actual o, si la región está activa y selecciona un grupo válido de secciones relacionadas con diff, el tipo de estas secciones, es decir, hunks o archivos. Si SECCION (o si la sección actual que es nil) es una sección hunk y la región comienza y termina dentro del cuerpo de una esa sección, entonces el tipo es region.

Si la opción estricta es distinta de nil, devuelve nil si el tipo de diff de la sección en el punto es untracked o si la sección en el punto no es realmente un diff sino una sección diffstat.

Actualización de Búferes

Todos los comandos que crean un nuevo búfer Magit o cambian lo que se está mostrando en un búfer existente lo hacen llamando a magit-mode-setup. Entre otras cosas, esta función establece los valores locales de default-directory (al nivel superior del repositorio), magit-refresh-function y magit-refresh-args.

Macro: magit-mode-setup BUFFER switch-func MODO refresh-func &opcional refresh-args

Esta función muestra y selecciona BUFFER, activa MODO y refresca una primera vez.

Esta función muestra y opcionalmente selecciona el BUFFER llamando a magit-mode-display-buffer con BUFFER, MODO y SWITCH-FUNC como argumentos. A continuación, establece el valor local de magit-refresh-function en REFRESH-FUNC y el de magit-refresh-args en REFRESH-ARGS. Por último, crea el contenido del búfer llamando a REFRESH-FUNC con REFRESH-ARGS como argumentos.

Todos los argumentos son evaluados antes de ser pasados a BUFFER.

Función: magit-mode-display-buffer MODO del BUFFER &opcional SWITCH-FUNCTION

Esta función muestra BUFFER en alguna ventana y lo selecciona. BUFFER puede ser un buffer o una cadena, el nombre de un buffer. Se devuelve el búfer.

A menos que BUFFER ya se muestre en el marco seleccionado, almacena la configuración anterior de la ventana como un valor local del buffer, para que pueda ser restaurado posteriormente por magit-mode-bury-buffer.

El búfer se muestra y selecciona utilizando SWITCH-FUNCTION. Si es nil, se usa pop-to-buffer si el modo principal del búfer actual deriva de magit-mode. En caso contrario, se usa switch-to-buffer.

Variable: magit-refresh-function

El valor de esta variable local del búfer es la función utilizada para actualizar el búfer actual. Se invoca con magit-refresh-args como argumentos.

Variable: magit-refreseh-args

La lista de argumentos usados por magit-refresh-function para refrescar el buffer actual. magit-refresh-function se llama con estos argumentos.

Normalmente, el valor se establece usando magit-mode-setup, pero en algunos casos también es útil proporcionar órdenes que puedan cambiar el valor. Por ejemplo, el transitorio magit-diff-refresh puede usarse para cambiar cualquiera de los argumentos usados para mostrar el diff, sin tener que especificar de nuevo qué diferencias deberían mostrarse, pero magit-diff-more-context, magit-diff-less-context y magit-diff-default-context cambian sólo el argumento -U<N>. En ambos casos esto se hace cambiando el valor de esta variable y luego llamando a esta función magit-refresh-function.

Convenciones

Vea también Finalización y confirmación

Tematización de Caras

El tema por defecto usa el azul para las ramas locales, el verde para las ramas remotas y el dorado (amarillo parduzco) para las etiquetas. Cuando cree un nuevo tema, probablemente debería seguir ese ejemplo. Si su tema ya utiliza otros colores, cíñase a ellos.

En versiones anteriores, estas caras de referencia solían tener un color de fondo y un recuadro a su alrededor. Las caras básicas por defecto ya no lo hacen, para hacer los buffers de Magit mucho menos ruidosos, y debería seguir ese ejemplo al menos en lo que respecta a las cajas. (Los recuadros se usaban en el pasado para solucionar un conflicto entre la superposición de resaltado y los fondos de las propiedades de texto. Eso ya no es necesario porque el resaltado ya no hace desaparecer otros colores de fondo). Alternativamente, puede mantener el color de fondo y/o la caja, pero entonces tendrá que tener especial cuidado en ajustar magit-branch-current en consecuencia. Por defecto se parece a magit-branch-local, pero con un recuadro (por defecto la primera es la única cara que usa un recuadro, exactamente para que sobresalga). Si la primera también usa una caja, hay que asegurarse de que difiere en algo de la segunda.

Las caras más difíciles de tematizar son las relacionadas con los diffs, los encabezados, el resaltado y la región. Hay caras que caen en los cuatro grupos - espera pasar algún tiempo haciéndolo bien.

Las caras más difíciles de tematizar son las relacionadas con los diffs, los encabezados, el resaltado y la región. Hay caras que caen en los cuatro grupos - espera pasar algún tiempo haciéndolo bien.

La cara de region en el tema por defecto, tanto en la variante clara como en la oscura, así como en muchos otros temas, distribuidos con Emacs o por terceros, es muy fea. Es común usar un color de fondo que realmente sobresale, lo cual es feo pero si ese fuera el único problema sería aceptable. Por desgracia, muchos temas también establecen el color de primer plano, lo que garantiza que todo el texto dentro de la región sea legible. Si no se hace así, puede haber casos en los que el color de primer plano esté demasiado cerca del color de fondo de la región como para ser legible. Pero también significa que el texto dentro de la región pierde todo el resaltado de sintaxis.

Considero que el trabajo realizado para que la cara de la región (region) sea correcta es un buen indicador de la calidad general de un tema. Mi recomendación para la cara de la región es la siguiente: use un color de fondo ligeramente diferente del color de fondo de la cara por defecto, y no establezca el color de primer plano en absoluto. Así, para un tema claro, podría usar un gris claro (posiblemente tintado) como color de fondo por defecto y un gris algo más oscuro para el fondo de la región. Esto debería ser suficiente para no colisionar con el color de primer plano de ninguna otra cara. Pero si algunas otras caras también establecen un gris claro como color de fondo, entonces también debe asegurarse de que no colisione con ellas (aunque en algunos casos podría ser aceptable).

Magit sólo usa la cara de región (region) cuando la región es "inválida" según su propia definición. En una memoria intermedia de Magit, la región se usa para seleccionar múltiples secciones hermanas, de modo que los comandos que la soportan actúan sobre todas estas secciones en lugar de sólo sobre la sección actual, o para seleccionar líneas dentro de una única sección de trozos. En todos los demás casos, la sección se considera inválida y Magit no actúa sobre ella. Pero estas secciones inválidas ocurren, bien porque el usuario aún no ha movido el punto lo suficiente como para hacerlo válido, bien porque quiere usar un comando que no es de Magit para actuar sobre la región, por ejemplo, kill-region.

Así que usar la cara region normal para secciones no válidas es una característica. Indica al usuario que Magit no podrá actuar sobre ella. Es aceptable si esa cara se ve un poco rara e incluso (pero menos) si colisiona con los colores de fondo de los encabezados de sección y otras cosas que tienen un color de fondo.

Magit resalta la sección actual. Si una sección tiene subsecciones, se resaltan todas. Esto se hace usando caras que tienen la palabra "highlight" en sus nombres. Para la mayoría de las secciones, magit-section-highlight se utiliza tanto para el cuerpo como para el encabezado. Al igual que la cara región, sólo debe establecer el color de fondo a algo similar al de por defecto. El color de fondo del resaltado debe ser diferente tanto del color de fondo de la región como del color de fondo por defecto (default).

Para las secciones relacionadas con diff, Magit utiliza varias caras para resaltar distintas partes de la sección o secciones seleccionadas. Tenga en cuenta que los encabezados de sección, a diferencia de todos los demás encabezados de sección, tienen por defecto un color de fondo, porque es útil tener separadores muy visibles entre secciones. Esa cara magit-diff-hunk-heading, debería ser diferente tanto de magit-diff-hunk-heading-highlight y magit-section-highlight, como de magit-diff-context y magit-diff-context-highlight. Por defecto lo hacemos cambiando el color de primer plano. Cambiar el color de fondo llevaría a complicaciones, y ya hay bastantes que no podemos evitar. (Tenga en cuenta también que, en general, es una buena idea que los encabezados de sección estén siempre en negrita, pero sólo para las secciones que tienen subsecciones).

Cuando hay una región válida que selecciona secciones hermanas relacionadas con diferencias, es decir, varios archivos o "hunks", los cuerpos de todas estas secciones utilizan las respectivas caras de resaltado, pero además los encabezados usan una de las caras magit-diff-file-heading-selection o magit-diff-hunk-heading-selection. Estas caras tienen que ser diferentes de las variantes de resaltado normales para proporcionar una indicación visual explícita de que la región está activa.

Cuando tematiza caras relacionadas con diff, comience por establecer la opción magit-diff-refine-hunk a all. Puede que personalmente prefiera refinar sólo el trozo (hunk) actual o no usar el refinamiento de trozos en absoluto, pero algunos de los usuarios de su tema quieren que todos los trozos refinados, así que tiene que atender a eso.

(Active también magit-diff-highlight-indentation, magit-diff-highlight-trailing, y magit-diff-paint-whitespace; e inserte algunos errores de espacio en blanco en el código que use para las pruebas).

Para las líneas añadidas hay que ajustar tres caras: magit-diff-added, magit-diff-added-highlight y diff-refined-added. Asegúrese de que esta última funciona bien con las dos anteriores, así como con smerge-other y diff-added. A continuación, haga lo mismo con las líneas eliminadas, las líneas de contexto, las líneas añadidas por nosotros y las líneas añadidas por ellos. Asegúrese también de que las respectivas caras añadidas, eliminadas y de contexto utilizan aproximadamente la misma saturación para las variantes resaltadas y no resaltadas. Asegúrese también de que los encabezados de archivo y diff funcionan bien con las líneas de contexto (por ejemplo, que tengan un aspecto diferente). Las caras de las líneas deben establecer tanto el color de primer plano como el de fondo. Por ejemplo, para las líneas añadidas use dos verdes diferentes.

Lo mejor es que el color de primer plano de las variantes resaltadas y no resaltadas sea el mismo, por lo que tendrá que encontrar un color que funcione bien en el fondo resaltado y no resaltado, en el fondo refinado y en el fondo de contexto resaltado. Cuando hay una región interna de trozos (hunks), el color de fondo de líneas añadidas y eliminadas se usa sólo dentro de esa región. Fuera de la región se utiliza el color de fondo de contexto resaltado. Esto facilita la visualización de lo que se está añadiendo al área de preparación. Con una región interna de trozos, el encabezado del trozo se muestra usando magit-diff-hunk-heading-selection, y también las líneas finas que se añaden alrededor de las líneas que caen dentro de la región. El color de fondo de esto tiene que ser lo suficientemente distinto de los otros colores de fondo implicados.

Nadie dijo que esto sería fácil. Si su tema se limita a un determinado conjunto de colores, debería hacer una excepción aquí. De lo contrario, sería imposible hacer que las diferencias se vean bien en todas y cada una de las variaciones. En realidad, es posible que desee atenerse a las definiciones por defecto para estas caras. Ya está avisado. También tenga en cuenta que si no lo hace bien, en algunos casos esto parecerá a los usuarios como errores en Magit - así que por favor hágalo bien o no lo haga.

Apéndice y Preguntas Frecuentes

En los dos nodos siguientes se enumeran las preguntas más frecuentes. Si desea consultar una lista de preguntas frecuentes y recientes, es decir, preguntas que aún no se han incluido en el manual, consulte https://github.com/magit/magit/wiki/FAQ.

Consulte también Herramientas de Depuración.

Cómo hacer

Cómo se pronuncia Magit

Tanto mu[m's] git como magi{c => t} están bien.

El eslogan reza "¡Es Magit! El cliente mágico de Git", así que tiene sentido pronunciar Magit como magia, teniendo en cuenta que C y T no suenan igual.

El alemán "Magie" no se pronuncia igual que el inglés "magic", así que si habla alemán puede utilizar el razonamiento anterior para justificar el uso de la pronunciación anterior; Mag{ie => it}.

También puede optar por la primera pronunciación simplemente porque le gusta más.

Errores y Problemas

Magit está lento

Vea Rendimiento y He cambiado varios miles de archivos a la vez y ahora Magit es inutilizable.

He cambiado varios miles de archivos a la vez y ahora Magit es inutilizable

Actualmente no se espera que Magit funcione bien en esas condiciones. Pero estaría bien que así fuera. Alcanzar un rendimiento satisfactorio en estas condiciones requerirá una profunda refactorización. No es una tarea fácil, pero espero encontrar tiempo para hacerla.

Por ahora, le recomendamos que use la línea de comandos para completar esta confirmación. Vea también Rendimiento.

Tengo problemas para hacer confirmaciones

Eso probablemente significa que Magit está teniendo problemas para encontrar un ejecutable emacsclient apropiado. Ver (con-editor)Configurando con-editor y (con-editor)Depurando.