3 ms·
As the author is aware of[1][2] the Git project uses this interdiff approach with email. - Patch series (PR equivalent) go through a round of reviews - Each v
by keybored 2y ago
As the author is aware of[1][2] the Git project uses this interdiff approach with email.
- Patch series (PR equivalent) go through a round of reviews
- Each version has a cover letter (like PR desription) unless it’s only a one-patch series
- Each version has that optional cover letter with each patch as a reply email to it
- The next version is a reply to the previous cover letter
- And each version 2 and above cover letter has a git-range-diff in it (courtesy of git-format-patch)
- And also a human/manual summary of changes between versions
- Optionally you can have little comments of each patch that are not part of the commit/patch message: just put it between the three dashes and the diff. Or use Git Notes and let it handle it for you (it will put it in the same space).
In turn there are no “address feedback” commits in the final (merged) series. Only the changes themselves.
Just look at any `[PATCH v2 0/...` or higher (v3...) email on the mailing list: https://lore.kernel.org/git/ https://lore.kernel.org/git/
Of course this isn’t the easiest workflow:
- Email
- 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
- You need to keep track of who to CC on the emails. Well, perhaps not if they are the same people throughout, but it is good courtesy to add people who reply to these versions to the CC list
- You need to harvest the email message id on the cover letters and use that `In-Reply-To`
Phew!
But this is quite sublime for reviewers and people who come back to the series years later:[3]
- All of the review in the same thread overview
- Each version moves the thread to the right
- Each patch (to be commit) is commented on individually
- You can reply to the commit message and the diff by quoting them directly
- The contributor will both give you the range diff (which will highlight diff changes and metadata changes like edited commit messages) and a manual summary of the changes
[1] https://news.ycombinator.com/item?id=41511649 https://news.ycombinator.com/item?id=41511649
[2] And it is with some trepidation that I bring this up because of the aversion some people have to email workflows. Because the “interdiff style” of PRs is useful!
[3] Git Notes `amlog` records the message id of the patch email where the commit came from
- another-acct 2y agoThis 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.
- keybored 2y ago> Never heard of "amlog" Everything I discussed was for the Git project. https://lore.kernel.org/git/20180724094501.GA3578@sigill.intra.peff.net/ https://lore.kernel.org/git/20180724094501.GA3578@sigill.int...
- keybored 2y agoAnd thanks for the feedback. It’s nice to find people who think this is interesting as well. :-)