[docs] Move code contribution from GettingStarted.rst to Contributing.rst

[MaskRay]

Summary

For code contribution, GettingStarted.rst duplicates information in Contributing.rst.
The dedicated Contributing.rst is a better place for code contribution, so move
the content there.

Notes:

• D41665 added Contributing.rst
• D110976 mentioned git cherry-pick e3659d43d8911e91739f3b0c5935598bceb859aa workaround

[MaskRay]

minor adjustment

[fhahn]

LGTM, thanks!

[nickdesaulniers]

llvm/docs/Contributing.rst

57–61

Consider adding punctuation to your added point, then making the whole bulleted list consistent.

91

Consider adding something to denote we also no longer use the mailing list?

and the llvm-commits mailing list is deprecated?

136–138

I'm a big fan of:

$ git rebase --onto main --root branch-with-change

which will rebase branch-with-change onto main, then checkout branch-with-change.

144

Isn't it necessary to merge branch-with-change into main before pushing main?

i.e. I would do:

$ git checkout main
$ git pull
$ git rebase --onto main --root branch-with-change
$ ninja check-$whatever
$ git checkout main
$ git merge -
$ git pull --rebase
$ git push

I guess you're suggesting pushing from the development branch? I guess that should be fine.

[MaskRay]

address comments

[MaskRay]

Thanks for the suggestion. This is mostly a doc move. The important part is that we agree that the code contribution part from GettingStarted.rst can be moved to Contributing.rst, which I assume we have achieved.
I did not intend to change too much wording and try to keep existing paragraphs. I'll push this shortly as @nickdesaulniers seems to have more planned improvement.

llvm/docs/Contributing.rst

91

There are quite a few llvm-commits which may need to be reworded after the Discourse migration.
I just add back a sentence to denote what we used to do.

144

Thanks for the suggestion. This is mostly a doc move from Contributing.rst. The important part is that we agree that the code contribution part from GettingStarted.rst can be moved to Contributing.rst, which I assume we have achieved.

llvm/docs/Contributing.rst

 
 Bigger Pieces of Work
 ---------------------
 In case you are interested in taking on a bigger piece of work, a list of
 interesting projects is maintained at the `LLVM's Open Projects page`_. In case
 you are interested in working on any of these projects, please post on the
 `Forum`_, so that we know the project is being worked on.
 
+.. _submit_patch:
+
 How to Submit a Patch
 =====================
 Once you have a patch ready, it is time to submit it. The patch should:
 
 * include a small unit test
 * conform to the :doc:`CodingStandards`. You can use the `clang-format-diff.py`_ or `git-clang-format`_ tools to automatically format your patch properly.
 * not contain any unrelated changes
 * be an isolated change. Independent changes should be submitted as separate patches as this makes reviewing easier.
+* has a single commit (unless stacked on another Differential), up-to-date with the upstream ``origin/main`` branch, and doesn't contain merges
 
 .. _format patches:
 
 Before sending a patch for review, please also try to ensure it is
 formatted properly. We use ``clang-format`` for this, which has git integration
 through the ``git-clang-format`` script. On some systems, it may already be
 installed (or be installable via your package manager). If so, you can simply
 run it -- the following command will format only the code changed in the most

 in order to update the last commit with all pending changes.
 
 .. note::
   If you don't already have ``clang-format`` or ``git clang-format`` installed
   on your system, the ``clang-format`` binary will be built alongside clang, and
   the git integration can be run from
   ``clang/tools/clang-format/git-clang-format``.
 
-
-To get a patch accepted, it has to be reviewed by the LLVM community. This can
-be done using `LLVM's Phabricator`_ or the llvm-commits mailing list.
-Please  follow :ref:`Phabricator#phabricator-reviews <phabricator-reviews>`
-to request a review using Phabricator.
+We don't currently accept GitHub pull requests, and you'll need to send patches
+via :ref:`Phabricator#phabricator-reviews <phabricator-reviews>`.
 
 To make sure the right people see your patch, please select suitable reviewers
 and add them to your patch when requesting a review. Suitable reviewers are the
 code owner (see CODE_OWNERS.txt) and other people doing work in the area your
 patch touches. If you are using Phabricator, add them to the `Reviewers` field
 when creating a review and if you are using `llvm-commits`, add them to the CC of
 your email.
 

 If you have received no comments on your patch for a week, you can request a
 review by 'ping'ing a patch by responding to the email thread containing the
 patch, or the Phabricator review with "Ping." The common courtesy 'ping' rate
 is once a week. Please remember that you are asking for valuable time from other
 professional developers.
 
 For more information on LLVM's code-review process, please see :doc:`CodeReview`.
 
+.. _commit_from_git:
+
+For developers to commit changes from Git
+-----------------------------------------
+
+Once a patch is reviewed, you should rebase it, re-test locally, and commit the
+changes to LLVM's main branch. This is done using `git push` if you have the
+required access rights. See `committing a change
+<Phabricator.html#committing-a-change>`_ for Phabricator based commits or
+`obtaining commit access <DeveloperPolicy.html#obtaining-commit-access>`_
+for commit access.
+
+Here is an example workflow using git. This workflow assumes you have an
+accepted commit on the branch named `branch-with-change`.
+
+.. code-block:: console
+
+  # Go to the branch with your accepted commit.
+  % git checkout branch-with-change
+  # Rebase your change onto the latest commits on Github.
+  % git pull --rebase origin main
+  # Rerun the appropriate tests if needed.
+  % ninja check-$whatever
+  # Check that the list of commits about to be pushed is correct.
+  % git log origin/main...HEAD --oneline
+  # Push to Github.
+  % git push origin HEAD:main
+
+LLVM currently has a linear-history policy, which means that merge commits are
+not allowed. The `llvm-project` repo on github is configured to reject pushes
+that include merges, so the `git rebase` step above is required.
+
+Please ask for help if you're having trouble with your particular git workflow.
+
+.. _git_pre_push_hook:
+
+Git pre-push hook
+^^^^^^^^^^^^^^^^^
+
+We include an optional pre-push hook that run some sanity checks on the revisions
+you are about to push and ask confirmation if you push multiple commits at once.
+You can set it up (on Unix systems) by running from the repository root:
+
+.. code-block:: console
+
+  % ln -sf ../../llvm/utils/git/pre-push.py .git/hooks/pre-push
 
 Helpful Information About LLVM
 ==============================
 :doc:`LLVM's documentation <index>` provides a wealth of information about LLVM's internals as
 well as various user guides. The pages listed below should provide a good overview
 of LLVM's high-level design, as well as its internals:
 
 :doc:`GettingStarted`

llvm/docs/GettingStarted.rst

 If you want to get a specific release (as opposed to the most recent revision),
 you can check out a tag after cloning the repository. E.g., `git checkout
 llvmorg-6.0.1` inside the ``llvm-project`` directory created by the above
 command.  Use `git tag -l` to list all of them.
 
 Sending patches
 ^^^^^^^^^^^^^^^
 
-Please read `Developer Policy <DeveloperPolicy.html#one-off-patches>`_, too.
-
-We don't currently accept github pull requests, so you'll need to send patches
-either via emailing to llvm-commits, or, preferably, via :ref:`Phabricator
-<phabricator-reviews>`.
-
-You'll generally want to make sure your branch has a single commit,
-corresponding to the review you wish to send, up-to-date with the upstream
-``origin/main`` branch, and doesn't contain merges. Once you have that, you
-can start `a Phabricator review <Phabricator.html>`_ (or use ``git show`` or
-``git format-patch`` to output the diff, and attach it to an email message).
-
-However, using the "Arcanist" tool is often easier. After `installing arcanist`_, you
-will also need to apply a fix to your arcanist repo in order to submit a patch:
-
-.. code-block:: console
-
-  % cd arcanist
-  % git fetch https://github.com/rashkov/arcanist update_cacerts
-  % git cherry-pick e3659d43d8911e91739f3b0c5935598bceb859aa
-
-Once this is all done, you can upload the latest commit using:
-
-.. code-block:: console
-
-  % arc diff HEAD~1
-
-Additionally, before sending a patch for review, please also try to ensure it's
-formatted properly. We use ``clang-format`` for this, which has git integration
-through the ``git-clang-format`` script. On some systems, it may already be
-installed (or be installable via your package manager). If so, you can simply
-run it -- the following command will format only the code changed in the most
-recent commit:
-
-.. code-block:: console
-
-  % git clang-format HEAD~1
-
-Note that this modifies the files, but doesn't commit them -- you'll likely want
-to run
-
-.. code-block:: console
-
-  % git commit --amend -a
-
-in order to update the last commit with all pending changes.
-
-.. note::
-  If you don't already have ``clang-format`` or ``git clang-format`` installed
-  on your system, the ``clang-format`` binary will be built alongside clang, and
-  the git integration can be run from
-  ``clang/tools/clang-format/git-clang-format``.
-
-
-.. _commit_from_git:
-
-For developers to commit changes from Git
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Once a patch is reviewed, you should rebase it, re-test locally, and commit the
-changes to LLVM's main branch. This is done using `git push` if you have the
-required access rights. See `committing a change
-<Phabricator.html#committing-a-change>`_ for Phabricator based commits or
-`obtaining commit access <DeveloperPolicy.html#obtaining-commit-access>`_
-for commit access.
-
-Here is an example workflow using git. This workflow assumes you have an
-accepted commit on the branch named `branch-with-change`.
-
-.. code-block:: console
-
-  # Go to the branch with your accepted commit.
-  % git checkout branch-with-change
-  # Rebase your change onto the latest commits on Github.
-  % git pull --rebase origin main
-  # Rerun the appropriate tests if needed.
-  % ninja check-$whatever
-  # Check that the list of commits about to be pushed is correct.
-  % git log origin/main...HEAD --oneline
-  # Push to Github.
-  % git push origin HEAD:main
-
-LLVM currently has a linear-history policy, which means that merge commits are
-not allowed. The `llvm-project` repo on github is configured to reject pushes
-that include merges, so the `git rebase` step above is required.
-
-Please ask for help if you're having trouble with your particular git workflow.
-
-
-.. _git_pre_push_hook:
-
-Git pre-push hook
-^^^^^^^^^^^^^^^^^
-
-We include an optional pre-push hook that run some sanity checks on the revisions
-you are about to push and ask confirmation if you push multiple commits at once.
-You can set it up (on Unix systems) by running from the repository root:
-
-.. code-block:: console
-
-  % ln -sf ../../llvm/utils/git/pre-push.py .git/hooks/pre-push
+See :ref:`Contributing <submit_patch>`.
 
 Bisecting commits
 ^^^^^^^^^^^^^^^^^
 
 See `Bisecting LLVM code <GitBisecting.html>`_ for how to use ``git bisect``
 on LLVM.
 
 Reverting a change

 This document is just an **introduction** on how to use LLVM to do some simple
 things... there are many more interesting and complicated things that you can do
 that aren't documented here (but we'll gladly accept a patch if you want to
 write something up!).  For more information about LLVM, check out:
 
 * `LLVM Homepage <https://llvm.org/>`_
 * `LLVM Doxygen Tree <https://llvm.org/doxygen/>`_
 * `Starting a Project that Uses LLVM <https://llvm.org/docs/Projects.html>`_
-
-.. _installing arcanist: https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/

llvm/docs/Phabricator.rst

 
 Requesting a review via the command line
 ----------------------------------------
 
 Phabricator has a tool called *Arcanist* to upload patches from
 the command line. To get you set up, follow the
 `Arcanist Quick Start`_ instructions.
 
+You may need to apply a fix to your arcanist repo in order to submit a patch:
+
+.. code-block:: console
+
+  % cd arcanist
+  % git fetch https://github.com/rashkov/arcanist update_cacerts
+  % git cherry-pick e3659d43d8911e91739f3b0c5935598bceb859aa
+
 You can learn more about how to use arc to interact with
 Phabricator in the `Arcanist User Guide`_.
 The basic way of creating a revision for the current commit in your local
 repository is to run:
 
 ::
 
   arc diff HEAD~