Update the attribution policy to use the 'Author' property of a git commit

[dsanders]

Summary

The older method of adding 'Patch by John Doe' is documented in the
Attribution of Changes section to support correct attribution of commits
that pre-date the adoption of git.

[aaron.ballman]

Thank you for working on this!

llvm/docs/DeveloperPolicy.rst

295

title, body -> a title and a body.

299

It would be helpful if we documented somewhere that the patch author should provide this information as part of their review when deciding who will commit the patch.

[lebedev.ri]

SGTM in general

llvm/docs/DeveloperPolicy.rst

295

Worth explicitly stating that there should be an empty line between the title and the body?
I.e. Separate the commit message into title and body with an empty line.

[echristo]

llvm/docs/DeveloperPolicy.rst

299

That and if you wouldn't mind a couple of actual command line examples would be nice too.

[dsanders]

Small changes for review comments

[dsanders]

llvm/docs/DeveloperPolicy.rst

299

It would be helpful if we documented somewhere that the patch author should provide this information as part of their review when deciding who will commit the patch.

Sure. I'm pretty sure I've seen a suitable place but I'm having trouble finding it at the moment. I'll keep looking

That and if you wouldn't mind a couple of actual command line examples would be nice too.

For this, I've just changed the current command to a realistic example. Hopefully [e-mail] isn't an address that's in use.

[dsanders]

Add a bit about asking someone to commit for you so that we can document
providing the information needed for the Author property

llvm/docs/DeveloperPolicy.rst

299

It would be helpful if we documented somewhere that the patch author should provide this information as part of their review when deciding who will commit the patch.

Sure. I'm pretty sure I've seen a suitable place but I'm having trouble finding it at the moment. I'll keep looking

I can't find the place where I saw a mention of asking someone to commit for you so I suspect I'm imagining it. I've added a paragraph to "Obtaining commit access" for this

[mehdi_amini]

LGTM, please wait for the others that commented here to approve as well.

[aaron.ballman]

LGTM!

[dsanders]

Thanks everyone. Landed in a5230ac10b0

[lattner]

This looks great!

llvm/docs/DeveloperPolicy.rst

 convey the rationale of the change (without delving too much in detail). It
 also should avoid being vague or overly specific. For example, "bits were not
 set right" will leave the reviewer wondering about which bits, and why they
 weren't right, while "Correctly set overflow bits in TargetInfo" conveys almost
 all there is to the change.
 
 Below are some guidelines about the format of the message itself:
 
-* Separate the commit message into title, body and, if you're not the original
-  author, a "Patch by" attribution line (see below).
+* Separate the commit message into title, body.
+
+* If you're not the original author, ensure the 'Author' property of the commit is
+  set to the original author and the 'Committer' property is set to yourself.
+  You can use ``git commit --amend --author="name/nickname <email>`` to
+  correct the author property if it is incorrect. See `Attribution of Changes`_
+  for more information including the method we used for attribution before the
+  project migrated to git.
 
 * The title should be concise. Because all commits are emailed to the list with
   the first line as the subject, long titles are frowned upon.  Short titles
   also look better in `git log`.
 
 * When the changes are restricted to a specific part of the code (e.g. a
   back-end or optimization pass), it is customary to add a tag to the
   beginning of the line in square brackets.  For example, "[SCEV] ..."
   or "[OpenMP] ...". This helps email filters and searches for post-commit
   reviews.
 
 * The body, if it exists, should be separated from the title by an empty line.
 
 * The body should be concise, but explanatory, including a complete
   reasoning.  Unless it is required to understand the change, examples,
   code snippets and gory details should be left to bug comments, web
   review or the mailing list.
 
 * If the patch fixes a bug in bugzilla, please include the PR# in the message.
 
-* `Attribution of Changes`_ should be in a separate line, after the end of
-  the body, as simple as "Patch by John Doe.". This is how we officially
-  handle attribution, and there are automated processes that rely on this
-  format.
-
 * Text formatting and spelling should follow the same rules as documentation
   and in-code comments, ex. capitalization, full stop, etc.
 
 * If the commit is a bug fix on top of another recently committed patch, or a
   revert or reapply of a patch, include the svn revision number of the prior
   related commit. This could be as simple as "Revert rNNNN because it caused
   PR#".
 

 
 Also, don't commit patches authored by others unless they have submitted the
 patch to the project or you have been authorized to submit them on their behalf
 (you work together and your company authorized you to contribute the patches,
 etc.). The author should first submit them to the relevant project's commit
 list, development list, or LLVM bug tracker component. If someone sends you
 a patch privately, encourage them to submit it to the appropriate list first.
 
+Our previous version control system (subversion) did not distinguish between the
+author and the committer like git does. As such, older commits used a different
+attribution mechanism. The previous method was to include "Patch by John Doe."
+in a separate line of the commit message and there are automated processes that
+rely on this format.
 
 .. _IR backwards compatibility:
 
 IR Backwards Compatibility
 --------------------------
 
 When the IR format has to be changed, keep in mind that we try to maintain some
 backwards compatibility. The rules are intended as a balance between convenience