Démarrer un message de validation git avec un hachage (#)

283

Git traite les lignes commençant par des #lignes de commentaire lors de la validation. cela est très ennuyeux lorsque vous travaillez avec un système de suivi des tickets et que vous essayez d'écrire le numéro de ticket au début de la ligne, par exemple

#123 salt hashed passwords

git supprimera simplement la ligne du message de validation. existe-t-il un moyen d'échapper au hachage? j'ai essayé \et !, mais rien ne fonctionne. les espaces avant #sont préservés, ils ne sont donc pas non plus une solution de travail au problème.

— knittl
source

8

@AlexBudovski parce qu'il y a de la valeur dans la brièveté.

— Xavi

8

Depuis git 1.8.2 (février 2013), git config core.commentcharpermet de configurer ce caractère de commentaire. Voir ma réponse ci

— VonC

3

Depuis Git v2.0.0 (2014.05.21) git commit --cleanup=scissorssera plus flexible. Voir le détail dans ma réponse

— Sungam

4

Je dois dire que je suis surpris que les gens de GitHub n'aient pas pensé à ce problème lorsqu'ils ont décidé de marquer les numéros de problème avec des hachages!

— Michael Scheper

1

@Michael Pour être juste, cette convention a déjà été utilisée par Mantis, Trac, Redmine et probablement d'autres. Je suppose que GitHub a juste décidé de le suivre au lieu de réinventer la roue. Voir stackoverflow.com/questions/40495/…

— kelvin

235

Ce comportement fait partie du comportement de git commit«nettoyage» par défaut de «. Si vous souhaitez conserver les lignes commençant par, #vous pouvez utiliser un autre mode de nettoyage.

Par exemple

git commit --cleanup=whitespace

Si vous faites cela, vous devez faire attention à supprimer toutes les #lignes que vous ne souhaitez pas voir apparaître dans le commit.

— CB Bailey
source

La question suivante est: où puis-je modifier les commentaires du message de validation que git introduit qui commencent par défaut par un #?

— Alex

2

@Alex: Il est contrôlé par la commit.templatevariable de configuration git.

— CB Bailey

23

Cela fonctionne également très bien pour modifier les validations existantes. Par exemple:git commit --amend --cleanup=whitespace

— James Andres

@CharlesBailey: Je m'attendais à me débarrasser du texte prédéfini avec git commit -t / dev / null mais cela montre toujours que

— Alex

Comme vous pouvez avoir un message de validation de "# 123 Commit message" ainsi que des commentaires dans des clients tels que GitHub pour Mac et SourceTree, je suppose que c'est ce que ces clients font oui?

— Phil Ostler

134

Notez que, depuis git1.8.2 (février 2013) , vous pouvez utiliser un caractère différent de ' #' pour la ligne commentée dans le message de validation.

Cela vous permet d'utiliser ' #' pour votre référence de numéro de bogue.

Les diverses lignes "d'indice" que Git donne quand il demande à l'utilisateur de modifier les messages dans l'éditeur sont commentées avec " #" par défaut.

La core.commentCharvariable de configuration peut être utilisée pour personnaliser ce ' #' en un caractère différent.

En théorie, vous pourriez mettre un core.commentCharmot (plusieurs caractères), mais git 2.0.x / 2.1 sera plus strict (Q3 2014).

Voir commit 50b54fd par Nguyễn Thái Ngọc Duy ( pclouds) :

config: soyez strict sur core.commentChar

Nous ne prenons pas en charge les chaînes de commentaires (du moins pas encore). Et le codage de caractères multi-octets pourrait également être mal interprété.

Le test avec deux virgules est mis à jour car il viole cela. Il est ajouté avec le correctif introduit core.commentChardans eff80a9 (Autoriser le "commentaire personnalisé" personnalisé - 16/01/2013). Je ne comprends pas pourquoi ce comportement est souhaité.

git 2.0.x / 2.1 (Q3 2014) ajoutera une sélection automatique pour core.commentChar:
Voir commit 84c9dc2

Quand core.commentCharest " auto", le caractère de commentaire commence par ' #' comme par défaut mais s'il est déjà dans le message préparé, trouvez un autre caractère dans un petit sous-ensemble. Cela devrait empêcher les surprises car git supprime certaines lignes de manière inattendue.

Notez que git n'est pas assez intelligent pour reconnaître ' #' comme le caractère de commentaire dans les modèles personnalisés et le convertir si le caractère de commentaire final est différent.
Il pense que les lignes «#» dans les modèles personnalisés font partie du message de validation. Ne l'utilisez donc pas avec des modèles personnalisés.

La liste des personnages candidats pour "auto" est:

# ; @ ! $ % ^ & | :

Cela signifie qu'une commande comme git commit -m '#1 fixed issue'basculera automatiquement le commentChar sur ' ;', car ' #' a été utilisé dans le message de validation.

— VonC
source

1

Pour corriger la syntaxe HL après cela, consultez cette question connexe: stackoverflow.com/questions/16164624/…

— Alois Mahdal

@Guten True, j'ai reformulé la réponse pour refléter cela.

— VonC

1

@newbyca avec quelle version de git voyez-vous qui n'est pas pris en charge lors d'un rebase interactif?

— VonC

2

Donc, pour régler cela, vous pouvez faire, par exemple:$ git config --global core.commentchar ';'

— davetapley

6

J'adore cette réponse. Oneliner pour la nouvelle solution suggérée:git config --global core.commentChar auto

— aross

81

Les réponses ici sont bonnes et détaillées, mais pour un git noob comme moi, la personnalisation des options de configuration de git n'est pas si évidente. Voici un exemple pour passer de #à ;pour les caractères de commentaire:

git config core.commentChar ";"

C'est tout ce que vous devez faire.

— Matthieu Napoli
source

3

Cela modifie également le texte commenté par défaut que git ajoute à un message de validation lorsque l'on utilise git commitpour ouvrir l'éditeur configuré pour modifier un message de validation!

— Michael Trouw

1

Pour les correctifs ponctuels, utilisez ceci: git -c core.commentChar="|" commit --amend(remplacez |par ce que vous voulez).

— Droogans

62

Vous pouvez utiliser l'option de ligne de commande -m:

git commit -m "#123 fixed"

— Olivier Verdier
source

35

Mais c'est un horrible message de validation. assurez-vous d'inclure ce qu'était le bug et comment il a été corrigé

— Good Person

3

les messages de commit sont corrects tant qu'il y a un certain nombre de bugs

— Trident D'Gao

6

Pas si le système de suivi des bogues est soudainement corrompu et que vous n'avez pas de sauvegarde! :)

— caveman_dick

38

Si vous faites un rebase interactif, alors lorsque vous enregistrez votre message de validation sans rien (car #au début, il en a fait un commentaire et donc il a été ignoré) git vous montrera quoi faire:

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

Donc, modifiez simplement le message:

git commit --amend -m "#123 salt hashed passwords"

et continuez le rebase:

git rebase --continue

— Owain Williams
source

C'est correct pour quelqu'un qui a déjà poussé le commit, mais qui veut changer le message

— Hoang Trinh

Cela s'applique également aux nouveaux validations si vous entrez un message à l'aide de votre éditeur et qu'il a un hachage au début.

— Owain Williams

29

git commit --cleanup=scissorsDevrait être utilisé. Il est ajouté à Git v2.0.0 le 2014.05.21

de git commit --help

--cleanup=<mode>
  scissors
    Same as whitespace, except that everything from (and including) the line
    "# ------------------------ >8 ------------------------" is truncated if the message
    is to be edited. "#" can be customized with core.commentChar.

— Sungam
source

Je ne comprends pas en quoi c'est mieux que d'utiliser commit.cleanup = whitespaceet de supprimer des # …commentaires à la main, comme l'a déjà suggéré @CharlesBailey. scissors-mode nettoie en plus la syntaxe des ciseaux utilisée par git format-patch/ mailinfo/ am; il n'utilise pas la …-- >8 --…syntaxe lors de l'ajout de commentaires pour valider les messages .

— Slipp D. Thompson

1. Je pense que c'est mieux parce que je n'ai pas besoin de "supprimer les # ...commentaires trop fort. 2. Je ne suis pas sûr de la deuxième partie de votre commentaire, le scissorsmode est définitivement dans git commit --help. Quelle version de gitvous utilisez-vous? @ SlippD.Thompson

— Sungam

Hein? whitespaceLe mode offre la suppression de 1. les lignes vides de début et de fin, 2. les espaces de fin, 3. la réduction des lignes vides consécutives. scissorsoffre le dépouillement de 1. les lignes vides de début et de fin, 2. les espaces vides de fin, 3. l'effondrement des lignes vides consécutives, 4. tout (y compris) la ligne # -…- >8 -…-. Cependant, les lignes de ciseaux ( # -…- >8 -…-) ne sont insérées que lorsque vous utilisez git-format-patch/ mailinfo/ am. Par conséquent, pour un flux de travail normal git-commit/ merge/ rebase/ cherry-pick, le scissorsmode de suppression n'offre aucun avantage par rapport au whitespacemode. v2.11.0

— Slipp D. Thompson

@ SlippD.Thompson Quelle version de git utilisez-vous? J'utilise 2.8.3 et git commit --cleanup=scissors DOIT ajouter la # ------------------------ >8 ------------------------ligne avant l' git statusinfo. Comme ci-dessous: `# ------------------------> 8 ------------------- ----- # Ne touchez pas la ligne ci-dessus. # Tout ce qui suit sera supprimé. # On branch master # # Initial commit # # Modifications à valider: # nouveau fichier: .gitignore `

— Sungam

1

Je crois que je suis allé au fond des choses. Git insère en effet l' # ------------------------ >8 ------------------------avant le statut txt "On dirait que vous pourriez être ..." _ lors de l'utilisation scissors; cependant, il insère la ligne de ciseaux après le # Conflicts: …texte. J'avais commit.status = falseinstallé mon .gitconfig, donc je ne voyais aucun texte d'état, seulement le texte des conflits. Je me suis trompé; changer pour voter.

— Slipp D. Thompson,

3

Utilisez un préfixe différent pour le numéro de ticket. Ou ajoutez un mot au numéro du ticket, comme "Bug # 42". Ou ajoutez un seul espace à la ligne; si vous souhaitez supprimer cet espace, vous pouvez ajouter un crochet de validation pour cela.

Personnellement, je préférerais que ce type de manipulation de message de validation ne soit pas effectué par un hook, car cela peut être très irritant lorsqu'il se déclenche lorsque vous ne le souhaitez pas. La solution la plus simple est probablement de repenser le problème.

— wilhelmtell
source

1

une formulation différente n'est qu'une solution de contournement au problème. si les directives du projet indiquent qu'un message de validation doit commencer par l'identifiant du ticket, cela ne fonctionnera pas. et un hook post-commit est très moche. je pense que je devrais signaler ce "bug" aux développeurs de git

— knittl

Ne vous embêtez pas, ce serait faux. Ne demandez pas aux développeurs git de travailler selon vos directives. Vous ne demanderiez pas à Dennis Ritchie de changer le langage C pour qu'il prenne en charge la convention des noms de variable commençant par un caractère de hachage, non? Il en va de même ici. Si les messages de validation autorisent les commentaires, cela ajoute la prise en charge de choses intéressantes, comme l'ouverture de l'éditeur de validation avec le diff ajouté et commenté afin que vous n'ayez pas à vous souvenir de vos modifications exactes. Qu'est-ce qui ne va pas avec la préservation du premier caractère spatial?

— wilhelmtell

1

soutenir les caractères d'échappement dans le message de validation de git ne serait pas si grave

— knittl

5

C'est une demande de fonctionnalité parfaitement raisonnable. Surtout à la lumière du fait que Trac, AFAICT, n'associe pas de commit à une fiche de bug si le message de commit ne commence pas par le numéro de slip, en commençant par un hachage. Ce n'est donc pas seulement les normes de quelqu'un, c'est la syntaxe requise d'un outil. Laissez les développeurs Git décider si cela vaut la peine ou non. (Et oui, Trac pourrait également résoudre le problème. Il n'y a rien de mal à demander à Git de faire ce qu'il peut aussi.)

— Luke Maurer

"Surtout à la lumière du fait que Trac, AFAICT, n'associe pas de commit à un bug si le message de commit ne commence pas par le numéro de slip, en commençant par un hachage." - dans mon expérience limitée avec Trac, quelque chose comme #xxxse produire n'importe où dans le message de validation sera lié au problème. Il n'est pas nécessaire que ce soit au début de la validation. Peut-être que c'est quelque chose qui a changé au cours des cinq dernières années?

— Guildenstern

1

Tous mes engagements commencent par #issueNumberdonc j'ai mis ce passe-partout à mon vim .git/hooks/commit-msg:

NAME=$(git branch | grep '*' | sed 's/* //') 
echo "$NAME"' '$(cat "$1") > "$1"

Supposons donc que nous ayons une branche #15et que nous fassions un message de validation add new awesome feature. Avec cette approche, le message final de validation sera #15 add new awesome feature.

— valignatev
source