confused you, point out something
  you found exceptionally well-written, etc.

- In particular, uplifting feedback goes a long way towards
  encouraging contributors to participate more actively in the Git
  community.

==== Performing your review
- Provide your review comments per-patch in a plaintext "Reply-All" email to the
  relevant patch. Comments should be made inline, immediately below the relevant
  section(s).

- You may find that the limited context provided in the patch diff is sometimes
  insufficient for a thorough review. In such cases, you can review patches in
  your local tree by either applying patches with linkgit:git-am[1] or checking
  out the associated branch from https://github.com/gitster/git once the series
  is tracked there.

- Large, complicated patch diffs are sometimes unavoidable, such as when they
  refactor existing code. If you find such a patch difficult to parse, try
  reviewing the diff produced with the `--color-moved` and/or
  `--ignore-space-change` options.

- If a patch is long, you are encouraged to delete parts of it that are
  unrelated to your review from the email reply. Make sure to leave enough
  context for readers to understand your comments!

- If you cannot complete a full review of a series all at once, consider letting
  the author know (on- or off-list) if/when you plan to review the rest of the
  series.

Completing a review
~~~~~~~~~~~~~~~~~~~
Once each patch of a series is reviewed, the author (and/or other contributors)
may discuss the review(s). This may result in no changes being applied, or the
author will send a new version of their patch(es).

After a series is rerolled in response to your or others' review, make sure to
re-review the updates. If you are happy with the state of the patch series,
explicitly indicate your approval (typically with a reply to the latest
version's cover letter). Optionally, you can let the author know that they can
add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
in a later iteration of the series.

Finally, subsequent "What's cooking" emails may explicitly ask whether a
reviewed topic is ready for merging to the `next` branch (typically phrased
"Will merge to \'next\'?"). You can help the maintainer and author by responding
with a short description of the state of your (and others', if applicable)
review, including the links to the relevant thread(s).

Terminology
-----------
nit: ::
	Denotes a small issue that should be fixed, such as a typographical error
	or misalignment of conditions in an `if()` statement.

aside: ::
optional: ::
non-blocking: ::
	Indicates to the reader that the following comment should not block the
	acceptance of the patch or series. These are typically recommendations
	related to code organization & style, or musings about topics related to
	the patch in question, but beyond its scope.

s/<before>/<after>/::
	Shorthand for "you wrote <before>, but I think you meant <after>," usually
	for misspellings or other typographical errors. The syntax is a reference
	to "substitute" command commonly found in Unix tools such as `ed`, `sed`,
	`vim`, and `perl`.

cover letter::
	The "Patch 0" of a multi-patch series. This email describes the
	high-level intent and structure of the patch series to readers on the
	Git mailing list. It is also where the changelog notes and range-diff of
	subsequent versions are provided by the author.
+
On single-patch submissions, cover letter content is typically not sent as a
separate email. Instead, it is inserted between the end of the patch's commit
message (after the `---`) and the beginning of the diff.

#leftoverbits::
  Used by either an author or a reviewer to describe features or suggested
  changes that are out-of-scope of a given patch or series, but are relevant
  to the topic for the sake of discussion.

See Also
--------
link:MyFirstContribution.html[MyFirstContribution]