Code Review and Maintenance Process

it is turned on; the Git list rejects HTML email. Please also follow the mailing list etiquette outlined in the https://kernel.googlesource.com/pub/scm/git/git/+/todo/MaintNotes[Maintainer's Note], which are similar to etiquette rules in most open source communities surrounding bottom-posting and inline replies. When you're making changes to your code, it is cleanest - that is, the resulting commits are easiest to look at - if you use `git rebase -i` (interactive rebase). Take a look at this https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch10.html[overview] from O'Reilly. The general idea is to modify each commit which requires changes; this way, instead of having a patch A with a mistake, a patch B which was fine and required no upstream reviews in v1, and a patch C which fixes patch A for v2, you can just ship a v2 with a correct patch A and correct patch B. This is changing history, but since it's local history which you haven't shared with anyone, that is okay for now! (Later, it may not make sense to do this; take a look at the section below this one for some context.) [[after-approval]] === After Review Approval The Git project has four integration branches: `seen`, `next`, `master`, and `maint`. Your change will be placed into `seen` fairly early on by the maintainer while it is still in the review process; from there, when it is ready for wider testing, it will be merged into `next`. Plenty of early testers use `next` and may report issues. Eventually, changes in `next` will make it to `master`, which is typically considered stable. Finally, when a new release is cut, `maint` is used to base bugfixes onto. As mentioned at the beginning of this document, you can read `Documents/SubmittingPatches` for some more info about the use of the various integration branches. Back to now: your code has been lauded by the upstream reviewers. It is perfect. It is ready to be accepted. You don't need to do anything else; the maintainer will merge your topic branch to `next` and life is good. However, if you discover it isn't so perfect after this point, you may need to take some special steps depending on where you are in the process. If the maintainer has announced in the "What's cooking in git.git" email that your topic is marked for `next` - that is, that they plan to merge it to `next` but have not yet done so - you should send an email asking the maintainer to wait a little longer: "I've sent v4 of my series and you marked it for `next`, but I need to change this and that - please wait for v5 before you merge it." If the topic has already been merged to `next`, rather than modifying your patches with `git rebase -i`, you should make further changes incrementally - that is, with another commit, based on top of the maintainer's topic branch as detailed in https://github.com/gitster/git. Your work is still in the same topic but is now incremental, rather than a wholesale rewrite of the topic branch. The topic branches in the maintainer's GitHub are mirrored in GitGitGadget, so if you're sending your reviews out that way, you should be sure to open your PR against the appropriate GitGitGadget/Git branch. If you're using `git send-email`, you can use it the same way as before, but you should generate your diffs from `<topic>..<mybranch>` and base your work on `<topic>` instead of `master`.

This section outlines the etiquette for email communication and the process of updating code after review approval, including the use of interactive rebase, the Git project's integration branches, and the steps to take when changes are needed after a topic has been merged to 'next', including sending emails to the maintainer and making incremental changes to the topic branch.