Iniciar un mensaje de confirmación de Git con una marca hash (#)
Git trata las líneas que comienzan con #(hash, signo numérico, octothorpe, signo de libra) como líneas de comentarios al realizar la confirmación. Esto es muy molesto cuando se trabaja con un sistema de seguimiento de tickets y se intenta escribir el número del ticket al principio de la línea, por ejemplo.
#123 salt hashed passwords
Git simplemente eliminará la línea del mensaje de confirmación. ¿Hay alguna manera de escapar del hash? Lo intenté \y !, pero nada funciona. Se conserva el espacio en blanco anterior #, por lo que tampoco es una solución funcional al problema.
Este comportamiento es parte del git commitcomportamiento de "limpieza" predeterminado. Si desea mantener las líneas que comienzan con, #puede utilizar un modo de limpieza alternativo.
P.ej
git commit --cleanup=whitespace
Si hace esto, debe tener cuidado de eliminar todas #las líneas que no desea que aparezcan en la confirmación.
Tenga en cuenta que, desde git1.8.2 (febrero de 2013) , puede utilizar un carácter diferente a " #" para la línea comentada en el mensaje de confirmación.
Eso le permite usar ' #' para la referencia de su número de error.
Varias líneas de "pistas" que Git proporciona cuando le pide al usuario que edite mensajes en el editor están comentadas con '
#' de forma predeterminada.La
core.commentCharvariable de configuración se puede utilizar para personalizar este '#' con un carácter diferente.
En teoría, podrías poner una core.commentCharpalabra (varios caracteres), pero git 2.0.x/2.1 será más estricto (tercer trimestre de 2014).
Ver el compromiso 50b54fd de Nguyễn Thái Ngọc Duy ( pclouds) :
configuración: sea estricto con core.commentChar
No admitimos cadenas de comentarios (al menos no todavía). Y la codificación de caracteres multibyte también podría malinterpretarse.
La prueba con dos comas se actualiza porque viola esto. Se agrega con el parche que se introduce
core.commentCharen eff80a9 (Permitir "carácter de comentario" personalizado - 2013-01-16). No me queda claro por qué se desea ese comportamiento.
git 2.0.x/2.1 (tercer trimestre de 2014) agregará una selección automática para core.commentChar:
Ver confirmación 84c9dc2
Cuando
core.commentChares "auto", el carácter de comentario comienza con '#' como de forma predeterminada, pero si ya está en el mensaje preparado, busque otro carácter en un subconjunto pequeño. Esto debería evitar sorpresas porque git elimina algunas líneas inesperadamente.Tenga en cuenta que git no es lo suficientemente inteligente como para reconocer '
#' como carácter de comentario en plantillas personalizadas y convertirlo si el carácter de comentario final es diferente.
Piensa en líneas '#' en plantillas personalizadas como parte del mensaje de confirmación. Así que no uses esto con plantillas personalizadas.
La lista de caracteres candidatos para "auto" es:
# ; @ ! $ % ^ & | :
Eso significa que un comando como git commit -m '#1 fixed issue'cambiará automáticamente el comentarioChar a ' ;', porque #se usó ' ' en el mensaje de confirmación.
Consulte " Hacer un hash de cosas: usar #smensajes de confirmación en Git " por Tom Wright
La respuesta de Stackoverflow que vinculé anteriormente también menciona una función en Git que elegirá un carácter de comentario automáticamente, según los caracteres que use en los mensajes de confirmación.
git config --global core.commentChar autoSuena genial ¿verdad?
Desafortunadamente, solo cambia el carácter del comentario según las confirmaciones realizadas después de activarlo; no utiliza su historial de confirmaciones para informar la elección.En mi opinión, esta es una gran característica que se ve obstaculizada por una mala ejecución.
Parece una característica que sería efectiva sólo si estuviera activada de forma predeterminada:
- Un grupo de personas simplemente evitará el uso de hashes en las confirmaciones porque están familiarizados con las consecuencias.
- Otros (como nosotros) solo se darán cuenta de que necesitan cambiar el carácter del comentario cuando necesiten hacer una rebase. En esta situación no tiene sentido agregar una nueva confirmación solo para desencadenar el comportamiento deseado.
- Un tercer grupo de personas aceptará conscientemente desde el principio que necesitan cambiar el carácter predeterminado del comentario y simplemente elegirán una alternativa.
En otras palabras, tener esta función disponible como una opción no predeterminada no ayuda a prácticamente nadie.
Dado que tenerlo activado de forma predeterminada no dañaría a ningún usuario y eliminaría un problema para algunos usuarios, no puedo entender por qué este no es el caso.
Git no es famoso por su usabilidad, pero tener una solución disponible y no activarla parece innecesariamente hostil para el usuario.
Nota: Git 2.41 (segundo trimestre de 2023) agrega:
Véase el compromiso d3b3419 (27 de marzo de 2023) de Kristoffer Haugsbakk ( LemmingAvalanche) .
(Fusionado por Junio C Hamano -- gitster-- en el compromiso 5c93cfd , 31 de marzo de 2023)
config: le dice al usuario que esperamos un carácter ASCIIAprobado por: Kristoffer Haugsbakk
El compromiso 50b54fd ("
config: be estricto encore.commentChar", 2014-05-17, Git v2.1.0-rc0 - combinación incluida en el lote n.º 2 ) señala que "la codificación de caracteres multibyte también podría malinterpretarse" y, de hecho, una codificación multibyte El punto de código de bytes (no ASCII) no se acepta como un archivocore.commentChar.
El mensaje ahora es:
core.commentChar should only be one ASCII character
^^^^^
Las respuestas aquí son buenas y detalladas, pero para un novato de git como yo, personalizar las opciones de configuración de git no es tan obvio. Aquí hay un ejemplo para cambiar de #a ;para caracteres de comentario:
git config core.commentChar ";"
Eso es todo lo que necesitas hacer.
Puede utilizar la opción de línea de comando -m:
git commit -m "#123 fixed"
Si está haciendo una rebase interactiva, cuando guarde su mensaje de confirmación sin nada en él (porque al #principio lo convirtió en un comentario y, por lo tanto, se ignoró), git le mostrará qué hacer:
Aborting commit due to empty commit message.
Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords
This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
You can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
Entonces, simplemente modifique el mensaje:
git commit --amend -m "#123 salt hashed passwords"
y continuar la rebase:
git rebase --continue
