Re: generate commit messages for package updates

[Edouard Klein <edk@beaver-labs.com>]

Thank you Ricardo !

Writing commit messages by hand is a major pain, especially for
newcommers like me. For simple commits it took me more time to write the
message than to write the code. The mistakes I made writing the commit
messages made the reviewers lose time correcting them. Automating this
task away is exactly what we need :)


Ricardo Wurmus writes:

> Hi Guix,
>
> I’m currently working on upgrading all Bioconductor packages to the 3.11
> release.  The hardest work here is to write commit messages for the 200+
> packages that have changed.  Even with the “update” yasnippet and magit
> this takes a very long time.
>
> I wrote a little tool to reduce the amount of time needed to create
> commits.  It is not fully automatic yet as it requires my input to stage
> hunks, but the commit messages it produces take all input changes into
> account, which is something the “update” yasnippet does not do.
>
> After “guix refresh -t bioconductor -u”, manually verifying and
> implementing the suggested changes, and building all packages, I run
> “git add -p” to stage hunks that belong to the same package definition.
> Then I run the attached tool to make a commit:
>
>     ./committer.scm | git commit -F -
>
> The tool works by looking at the unified diff in the staging area and
> generating two S-expressions corresponding to the original package
> definition and the changed package definition, respectively.  It then
> looks at the inputs, propagated-inputs, and native-inputs fields and
> generates a GNU ChangeLog-style commit message describing the changes.
>
> Here’s an example diff:
>
> --8<---------------cut here---------------start------------->8---
> modified   gnu/packages/bioconductor.scm
> @@ -2701,29 +2701,32 @@ gene and isoform level using RNA-seq data")
>  (define-public r-karyoploter
>    (package
>      (name "r-karyoploter")
> -    (version "1.12.4")
> +    (version "1.14.0")
>      (source (origin
>                (method url-fetch)
>                (uri (bioconductor-uri "karyoploteR" version))
>                (sha256
>                 (base32
> -                "03jmfgmw35hrgn3pc5lq6pblzhfx9fp4l6dx50rp303lr7kjxp9v"))))
> +                "0h0gk4xd95k5phy6qcsv7j931d7gk3p24i2fg4mz5dsk110lpifs"))))
>      (build-system r-build-system)
>      (propagated-inputs
> -     `(("r-regioner" ,r-regioner)
> +     `(("r-annotationdbi" ,r-annotationdbi)
> +       ("r-bamsignals" ,r-bamsignals)
> +       ("r-bezier" ,r-bezier)
> +       ("r-biovizbase" ,r-biovizbase)
> +       ("r-digest" ,r-digest)
> +       ("r-genomeinfodb" ,r-genomeinfodb)
> +       ("r-genomicfeatures" ,r-genomicfeatures)
>         ("r-genomicranges" ,r-genomicranges)
>         ("r-iranges" ,r-iranges)
> -       ("r-rsamtools" ,r-rsamtools)
>         ("r-memoise" ,r-memoise)
> +       ("r-regioner" ,r-regioner)
> +       ("r-rsamtools" ,r-rsamtools)
>         ("r-rtracklayer" ,r-rtracklayer)
> -       ("r-genomeinfodb" ,r-genomeinfodb)
>         ("r-s4vectors" ,r-s4vectors)
> -       ("r-biovizbase" ,r-biovizbase)
> -       ("r-digest" ,r-digest)
> -       ("r-bezier" ,r-bezier)
> -       ("r-bamsignals" ,r-bamsignals)
> -       ("r-annotationdbi" ,r-annotationdbi)
>         ("r-variantannotation" ,r-variantannotation)))
> +    (native-inputs
> +     `(("r-knitr" ,r-knitr)))
>      (home-page "https://bioconductor.org/packages/karyoploteR/")
>      (synopsis "Plot customizable linear genomes displaying arbitrary data")
>      (description "This package creates karyotype plots of arbitrary genomes and
> --8<---------------cut here---------------end--------------->8---
>
> …and this is the generated commit message:
>
> --8<---------------cut here---------------start------------->8---
> gnu: r-karyoploter: Update to 1.14.0.
>
> * gnu/packages/bioconductor.scm (r-karyoploter): Update to 1.14.0.
> [propagated-inputs]: Add r-genomicfeatures.
> [native-inputs]: Add r-knitr.
> --8<---------------cut here---------------end--------------->8---
>
> Obviously, this can be improved by avoiding the staging area and
> operating on all hunks in all selected files, so that more than one
> commit can be made at a time.  But I thought I’d share this hack anyway,
> crude as it is.