Lines Matching refs:commit

92    it (or commit it directly if applicable).
114 of code review plus post-commit review for trusted maintainers.  Having both is
116 the right thing most of the time, and only commit patches without pre-commit
123 responsibility of a code owner is to ensure that a commit to their area of the
172 discretion, preferably as part of the commit landing the changes. Examples of
236 progress. The developer is welcome to re-commit the change after the problem has
244 Although we don't enforce the format of commit messages, we prefer that
258 * Separate the commit message into title and body separated by a blank line.
260 * If you're not the original author, ensure the 'Author' property of the commit is
263   ``git commit --amend --author="John Doe <[email protected]>"`` to correct the
275   or "[OpenMP] ...". This helps email filters and searches for post-commit
290 * If the commit is a bug fix on top of another recently committed patch, or a
291   revert or reapply of a patch, include the git commit hash of the prior
292   related commit. This could be as simple as "Revert commit NNNN because it
319   original commit thread with the reverting patch author.
328 * If a test case that demonstrates a problem is reported in the commit thread,
330 * If you receive substantial :ref:`post-commit review <post_commit_review>`
350   the commit thread asking for assistance.  We aren't trying to enumerate
356 * The commit message for the reverting commit should explain why patch
358 * It is customary to respond to the original commit email mentioning the
362   Where possible, we encourage sharing of test cases in commit threads, or
378   we encourage you to reply to the commit thread, give the author a bit to
381 * When re-applying a reverted patch, the commit message should be updated to
387 We grant commit access to contributors with a track record of submitting high
388 quality patches.  If you would like commit access, please send an email to
394 accept the invitation, you'll get commit access.
396 Prior to obtaining commit access, it is common practice to request that
397 someone with commit access commits on your behalf. When doing so, please
399 property of the commit.
402 on a commits mailing list soon after the commit lands (e.g. llvm-commits_).
404 commit to require a moderator to approve the email, so do not be concerned if a
405 commit does not immediately appear in the archives.
407 If you have recently been granted commit access, these policies apply:
409 #. You are granted *commit-after-approval* to all parts of LLVM. For
411    When approved, you may commit it yourself.
413 #. You are allowed to commit patches without approval which you think are
421    highly localized and the commit message should clearly state that the commit
425 #. You are allowed to commit patches without approval to those portions of LLVM
432    cause commit access to be revoked.
526 commit access may commit it for the author once appropriate (based on the
532 file describes higher-level contributions. If you commit a patch for someone
534 by the `commit messages`_ section. Overall, please do not add contributor names
537 Also, don't commit patches authored by others unless they have submitted the
540 etc.). The author should first submit them to the relevant project's commit
547 in a separate line of the commit message and there are automated processes that
669 *If your commit broke the build:*
682 * Revert the commit if this blocks your work, see revert_policy_ .