Re: [Libguestfs] [PATCH v2 1/3] generator: Move [camel_case] function from GoLang.ml to utils.ml as it will be used in Rust.ml as well

On Mon, Jun 26, 2023 at 05:29:25PM +0100, Richard W.M. Jones wrote: 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