orhun/git-cliff

`--prepend` cannot reliably identify the previous header

Ouverte

#712 ouverte le 17 juin 2024

Voir sur GitHubGuide contributeur
 (3 commentaires) (0 réaction) (0 personne assignée)Rust (308 forks)auto 404
bughelp wanted

Métriques du dépôt

Stars
 (12 040 étoiles)
Métriques de merge PR
 (Métriques PR en attente)

Description

Is there an existing issue for this?

  • I have searched the existing issues

Description of the bug

The CLI argument --prepend is supposed to result in git-cliff injecting the changelog for recent releases into an existing changelog.

  1. Remove the old header.
  2. Prepend the new releases' bodies.
  3. Prepend the new header.

Step 1 relied on the header being static between runs of git-cliff. It performed a simple string comparison between the existing CHANGELOG.md and the current value in the changelog.header variable. Since #697, changelog.header contains a template. Thus its value might change between runs and thus prevent detecting the old header.

Steps To Reproduce

  1. Set changelog.header to a template such that the output after rendering changes between releases.
  2. Create a new release.
  3. Run git-cliff with the --prepend flag.

Expected behavior

git-cliff should properly detect and replace the old header.

Screenshots / Logs

No response

Software information

  • After PR #698

Additional context

No response

Guide contributeur

Direction de recherche
Examinez l'implémentation de prepend dans la logique principale de génération du changelog. Identifiez comment l'en tête est actuellement apparié et comprenez l'impact du templating sur la comparaison statique des en têtes. Envisagez des approches alternatives pour détecter et remplacer l'ancien en tête lorsqu'il est généré à partir d'un template.
Stack technique
rust
Domaine
cli
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
RustGit
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
55