This is the comment I've been looking for! :) High-five!
Some remarks:
> - The next version is a reply to the previous cover letter
Not necessarily; sometimes the new version is not posted in-reply-to anything, but the cover letter includes a reference (usually message-id + web-archive URL) in the body. Depends on the project I guess.
> And each version 2 and above cover letter has a git-range-diff in it (courtesy of git-format-patch)
Wow, amazing. I'd been doing it manually; it's amazing that git can do this automatically now!
> Or use Git Notes and let it handle it for you
Finally someone knows about it :)
> - You ought to keep track of the base commit between versions (you could have rebased on the main branch)
> - You need to store versions of your branches
The latter solves the former. Also, patch sets are best formatted with "--base"; then people on the list know exactly what to apply the patches on top of.
I go farther: assuming you also push the patch set to some public URL (for easy fetching by the reviewers), those URLs then count as read-only and permanent, forever. Never delete them, never rebase them.
> - You need to keep track of who to CC on the emails
This is best solved by adding Cc: tags to the individual commit messages. Three reasons: (a) the final git log will capture who was CC'd, (b) these Cc: tags (being parts of the commit messages) survive rebases, (c) you can CC different patches to different people (the cover letter should be CC'd to everyone); which is handy when you modify multiple subsystems in the same series.
> You need to harvest the email message id on the cover letters and use that `In-Reply-To`
git-format-patch can prepare a skeleton for the cover letter too, and once edited manually, git-send-email can send it out together with the actual patches -- and handle the in-reply-to automatically.
Your point does stand if you send v2 "in-reply-to" v1. Or, if you send multiple patch sets (e.g. for multiple inter-operating projects) in-reply-to a common meta-cover-letter.
> [3] Git Notes `amlog` records the message id of the patch email where the commit came from
Never heard of "amlog"; however, you can pass "--message-id" to git-am, and then the message-ID of the patch email becomes part of the commit message. That's incredibly useful with mailing list archives that let you search for discussions by message-id.
Some remarks:
> - The next version is a reply to the previous cover letter
Not necessarily; sometimes the new version is not posted in-reply-to anything, but the cover letter includes a reference (usually message-id + web-archive URL) in the body. Depends on the project I guess.
> And each version 2 and above cover letter has a git-range-diff in it (courtesy of git-format-patch)
Wow, amazing. I'd been doing it manually; it's amazing that git can do this automatically now!
> Or use Git Notes and let it handle it for you
Finally someone knows about it :)
> - You ought to keep track of the base commit between versions (you could have rebased on the main branch) > - You need to store versions of your branches
The latter solves the former. Also, patch sets are best formatted with "--base"; then people on the list know exactly what to apply the patches on top of.
I go farther: assuming you also push the patch set to some public URL (for easy fetching by the reviewers), those URLs then count as read-only and permanent, forever. Never delete them, never rebase them.
> - You need to keep track of who to CC on the emails
This is best solved by adding Cc: tags to the individual commit messages. Three reasons: (a) the final git log will capture who was CC'd, (b) these Cc: tags (being parts of the commit messages) survive rebases, (c) you can CC different patches to different people (the cover letter should be CC'd to everyone); which is handy when you modify multiple subsystems in the same series.
> You need to harvest the email message id on the cover letters and use that `In-Reply-To`
git-format-patch can prepare a skeleton for the cover letter too, and once edited manually, git-send-email can send it out together with the actual patches -- and handle the in-reply-to automatically.
Your point does stand if you send v2 "in-reply-to" v1. Or, if you send multiple patch sets (e.g. for multiple inter-operating projects) in-reply-to a common meta-cover-letter.
> [3] Git Notes `amlog` records the message id of the patch email where the commit came from
Never heard of "amlog"; however, you can pass "--message-id" to git-am, and then the message-ID of the patch email becomes part of the commit message. That's incredibly useful with mailing list archives that let you search for discussions by message-id.