git send-email --subject-prefix="PATCH v4" --compose -14
Assigning a version number to each round of patches allows me to add a change log for the entire patch-set to the introductory mail, e.g.:
From: David DisseldorpSubject: [PATCH v4 00/14] add compression ioctl support This patch series adds support for the FSCTL_GET_COMPRESSION and FSCTL_SET_COMPRESSION ioctls, as well as the reporting of the current compression state via the FILE_ATTRIBUTE_COMPRESSED flag. Hooks are added to the Btrfs VFS module, which translates such requests into corresponding FS_IOC_GETFLAGS and FS_IOC_SETFLAGS ioctls. Changes since v3 (thanks for the feedback Jeremy): - fixed and split copy-chunk dest unlock change into separate commit Changes since v2: - Check for valid fsp file descriptors - Rebase atop filesystem specific selftest changes - Change compression fsctl permission checks to match Windows behaviour + Add corresponding smbtorture test Changes since v1: - Only use smb_fname and fsp args with GET_COMPRESSION. The smb_fname argument is only needed for the dosmode() code-path, fsp is used everywhere else. - Add an extra SetInfo(FILE_ATTRIBUTE_COMPRESSED) test. GIT: [PATCH v4 01/14] selftest/s3: expose share with FS applicable config ...
Change logs can also be added to individual patches using the --annotate parameter:
git send-email --annotate --subject-prefix="PATCH v2" -1
Subject: [PATCH v2] common: add CephFS support ... --- Changes since version 1: - Remove -ceph parameter for check and rely on $FSTYP instead
...
diff --git a/README.config-sections b/README.config-sections
Putting the change log between the first "---" and "diff --git a/..." lines ensures that it will be dropped when applying the patch via git-am.
[update 2016-11-03]
- Describe the --annotate parameter
"git send-email --annotate -v2 -1" will achieve the same.
ReplyDelete