carbon-language/carbon-lang
1
0
Fork 0
mirror of https://github.com/carbon-language/carbon-lang.git synced 2026-10-05 10:11:04 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity

Adjust md tab width to work better cross-markdown-parser (#124)

Browse Source 
We're running into issues with md handlers that expect this kind of 4-space indent. It should be cross-compatible with GH, so switch, even though it feels a little churny.

Manual edits are to:

- .prettierrc.yaml:
    - rename from .prettierrc
    - add tabWidth (primary change)
    - add trailingComma (fix vimPrettier skew)
- contribution_tools.md: Fix remarks about .prettierrc.yaml
- pre-commit-toc.js: indent, bullets
- pre-commit-proposal-list.py: indent of output

The rest is the result of `pre-commit run --all-files`

Unfortunately this'll probably depend on the change being propagated into PR branches, so I wouldn't be surprised if we see regressions for a bit. We'll also need to nudge people to update .vimrc's. Hopefully the pre-commit GH action helps catch issues.
This commit is contained in:
Jon Meow
2020-07-27 10:47:38 -07:00
committed by GitHub
parent 435ed95ab2
commit be116a46c9
26 changed files with 1278 additions and 1238 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/project/pull_request_workflow.md
+17 -16
View File
@@ -8,26 +8,27 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Carbon repositories follow a few basic principles:
- Development directly on the `trunk` branch and
[revert to green](#green-tests).
- Always use pull requests, rather than pushing directly.
- Changes should be small, incremental, and review-optimized.
- Preserve linear history by
[rebasing](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#rebase-and-merge-your-pull-request-commits)
or
[squashing](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits)
pull requests rather than using unsquashed merge commits.
- Development directly on the `trunk` branch and
[revert to green](#green-tests).
- Always use pull requests, rather than pushing directly.
- Changes should be small, incremental, and review-optimized.
- Preserve linear history by
[rebasing](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#rebase-and-merge-your-pull-request-commits)
or
[squashing](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits)
pull requests rather than using unsquashed merge commits.
These principles try to optimize for several different uses or activities with
version control:
- Continuous integration and bisection to identify failures and revert to green.
- Code review both at the time of commit and follow-up review after commit.
- Understanding how things evolve over time, which can manifest in different
ways:
- When were things introduced?
- How does the main branch and project evolve over time?
- How was a bug or surprising thing introduced?
- Continuous integration and bisection to identify failures and revert to
green.
- Code review both at the time of commit and follow-up review after commit.
- Understanding how things evolve over time, which can manifest in different
ways:
- When were things introduced?
- How does the main branch and project evolve over time?
- How was a bug or surprising thing introduced?
Note that this isn't a complete guide to doing code reviews, and just focuses on
the mechanical workflow and branch management. TODO: Add an explicit link to