answer these questions in your response messages, but often the
reason why reviewers asked these questions to understand what you meant
to write is because your patchset needed clarification to be understood.

Do not be satisfied by just answering their questions in your response
and hear them say that they now understand what you wanted to say.
Update your patches to clarify the points reviewers had trouble with,
and prepare your v2; the words you used to explain your v1 to answer
reviewers' questions may be useful thing to use.  Your goal is to make
your v2 clear enough so that it becomes unnecessary for you to give the
same explanation to the next person who reads it.

If you are going to push back on a comment, be polite and explain why you feel
your original is better; be prepared that the reviewer may still disagree with
you, and the rest of the community may weigh in on one side or the other. As
with all code reviews, it's important to keep an open mind to doing something a
different way than you originally planned; other reviewers have a different
perspective on the project than you do, and may be thinking of a valid side
effect which had not occurred to you. It is always okay to ask for clarification
if you aren't sure why a change was suggested, or what the reviewer is asking
you to do.

Make sure your email client has a plaintext email mode and 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