On Mon, Jun 26, 2023 at 05:29:25PM +0100, Richard W.M. Jones wrote:
>
> Thanks, this one is upstream in commit 557ed93df3.
Hello Tage, I'm looking forward to seeing your work this summer, and
congratulations on your first commit to libnbd!
Here's some advice to help on future patches.
First, I noticed you sent your v2 series without a cover letter (there
were mails for 1/3, 2/3, 3/3, but no 0/3), and in reply to the v1
thread rather than as an independent new thread. For projects that
rely on mail-based reviews, and reviewers that use mail clients that
properly display threads, this can bury your revisions and make it
harder to see that you have an updated version to be reviewed. I
suggest using:
git config format.coverletter auto
git config format.useautobase whenAble
which makes git generate a 0/N cover letter for anything larger than a
single patch, and includes the git commit your patch is based on
(where git can easily figure that out), all of which can aid
reviewers.
Next, if you'll compare Rich's commit with your original email, you'll
notice that Rich reformatted your commit message a bit. In
particular, you had a really long subject line, and no other content
in the commit message, because you wrote a single line in the git
commit window:
generator: Move [camel_case] function from GoLang.ml to utils.ml as it will
be used in Rust.ml as well
Rich rewrote it as:
generator: Move [camel_case] function from GoLang.ml to utils.ml
Simple code movement. This will be used in the future Rust bindings.
before adding his Reviewed-by: tag. In general, a good commit message
has a short summary that describes the WHAT (60 characters is a good
upper limit to strive for, 'git shortlog -50' can give you a feel for
how your summary compares to recent commits), then a free-form body
that describes the WHY (also good to keep this wrapped, around 70
columns). The WHY is important: both in the present (it explains why
the patch is worth applying, what reviewers should be looking for),
and in the future (if a git bisect lands on your patch, we want to
understand what the patch was doing without having to also do
archaeology in the mailing list archives of the same time frame).
Writing good commit messages is an art form that you learn over time,
so we don't mind tweaking things on your first few commits along your
journey; but the more commits you write, the more you want to reach
the point where your commits can be applied as-is -- because it
doesn't scale to make others touch up every commit.
Hope that helps!
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
