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

Switch from Prettier to Rumdl for Markdown formatting (#7423)

Browse Source 
Rumdl already appears to have _significantly_ fewer bugs than prettier,
and a solid LSP for editor integration.

The tool is: https://github.com/rvben/rumdl/

I've separated out the change across three commits for easier review.

The configuration tries to match the existing formatting, the changes to
the all the files are to correct issues found by the new tool.

Assisted-by: Antigravity with Gemini

---------

Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This commit is contained in:
Chandler Carruth
2026-06-26 21:42:01 +00:00
committed by GitHub
co-authored by Richard Smith
parent 6181259cf1
commit cfd1ed8484
90 changed files with 754 additions and 589 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/project/pull_request_workflow.md
+10 -10
View File
@@ -85,17 +85,17 @@ integration, and bisection. This means we typically squash pull requests into a
single commit when landing. We use two fundamental guides for deciding how to
split up pull requests:
1. Ensure that each pull request builds and passes any tests cleanly when you
request review and when it lands. This will ensure bisection and continuous
integration can effectively process them.
1. Ensure that each pull request builds and passes any tests cleanly when you
request review and when it lands. This will ensure bisection and continuous
integration can effectively process them.
2. Without violating the first point, try to get each pull request to be "just
right": not too big, not too small. You don't want to separate a pattern of
tightly related changes into separate requests when they're easier to review
as a set or batch, and you don't want to bundle unrelated changes together.
Typically you should try to keep the pull request as small as you can without
breaking apart tightly coupled changes. However, listen to your code reviewer
if they ask to split things up or combine them.
2. Without violating the first point, try to get each pull request to be "just
right": not too big, not too small. You don't want to separate a pattern of
tightly related changes into separate requests when they're easier to review
as a set or batch, and you don't want to bundle unrelated changes together.
Typically you should try to keep the pull request as small as you can without
breaking apart tightly coupled changes. However, listen to your code reviewer
if they ask to split things up or combine them.
While the default is to squash pull requests into a single commit, _during_ the
review you typically want to leave the development history undisturbed until the