ソースを参照

Add pre-commit check to remove trunk links from md files (#847)

Restricting this to just md files because maybe we'll reasonably want such links in source files, but would be fine removing that restriction if you're on board.

e.g., this won't change: https://github.com/carbon-language/carbon-lang/blob/trunk/common/string_helpers.cpp#L85
Jon Meow 4 年 前
コミット
8396527043

+ 5 - 0
.pre-commit-config.yaml

@@ -27,6 +27,11 @@ repos:
         args: ['--fix=lf']
       - id: trailing-whitespace
         exclude: '^(.*/testdata/.*\.golden)$'
+  - repo: https://github.com/mattlqx/pre-commit-search-and-replace
+    rev: 417c99dafb534d7517d9abc17f0293de3c915a72 # frozen: v1.0.5
+    hooks:
+      - id: search-and-replace
+        files: '\.md$'
   - repo: https://github.com/google/pre-commit-tool-hooks
     rev: 1d04a2848ac54d64bd6474ccec69aac45fa88414 # frozen: v1.1.1
     hooks:

+ 6 - 0
.pre-commit-search-and-replace.yaml

@@ -0,0 +1,6 @@
+# Part of the Carbon Language project, under the Apache License v2.0 with LLVM
+# Exceptions. See /LICENSE for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+
+- search: /https:\/\/github.com\/carbon-language\/carbon-lang\/blob\/trunk\//
+  replacement: /

+ 2 - 2
proposals/p0353.md

@@ -298,7 +298,7 @@ There is no easy place to put the increment in a `while` loop.
 Advantages:
 
 -   We need a plan for
-    [migrating both developers and code from C++](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code)
+    [migrating both developers and code from C++](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code)
     semisemis `for` loops, and providing them in Carbon is the easiest solution.
     -   Semisemis remain common in C++ code.
 -   Semisemis are much more flexible than range-based `for` loops.
@@ -310,7 +310,7 @@ Disadvantages:
     -   Syntax such as `for (int x : range(0, 3))` leaves less room for
         developer mistakes.
     -   Removing semisemi syntax will likely improve
-        [understandability of Carbon code](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write),
+        [understandability of Carbon code](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write),
         a language goal.
 -   If we add semisemi loops, it would be very difficult to get rid of them.
     -   Code using them should be expected to accumulate quickly, from both

+ 3 - 4
proposals/p0415.md

@@ -30,12 +30,11 @@ to their caller.
 
 ## Background
 
-The Carbon overview
-[contains](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#return)
-a "skeletal design" for `return`.
+The Carbon overview [contains](/docs/design/README.md#return) a "skeletal
+design" for `return`.
 
 Carbon aims for
-[_familiarity for experienced C++ developers with a gentle learning curve_](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code).
+[_familiarity for experienced C++ developers with a gentle learning curve_](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code).
 C++ returns from functions with a `return` statement, which is documented well
 [here](https://en.cppreference.com/w/cpp/language/return).
 

+ 3 - 3
proposals/p0438.md

@@ -40,9 +40,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 ## Problem
 
 We currently have
-[placeholder guidance on functions](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/functions.md).
-The intent of this proposal is to establish agreement on the basics, providing a
-baseline for future evolution.
+[placeholder guidance on functions](/docs/design/functions.md). The intent of
+this proposal is to establish agreement on the basics, providing a baseline for
+future evolution.
 
 ## Background
 

+ 1 - 1
proposals/p0444.md

@@ -113,7 +113,7 @@ can be moved to
 
 ## Rationale based on Carbon's goals
 
--   [Community and culture](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#community-and-culture):
+-   [Community and culture](/docs/project/goals.md#community-and-culture):
 
     -   GitHub Discussions offers a way to consolidate tools and make community
         forums easier to find.

+ 2 - 5
proposals/p0623.md

@@ -36,11 +36,8 @@ for (Shape x : shapes)
 ```
 
 Carbon adopted this design choice by default in proposals
-[#285](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0285.md),
-[#340](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0340.md),
-and
-[#353](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0353.md).
-But should we keep it?
+[#285](/proposals/p0285.md), [#340](/proposals/p0340.md), and
+[#353](/proposals/p0353.md). But should we keep it?
 
 ## Background
 

+ 1 - 1
proposals/p0676.md

@@ -79,7 +79,7 @@ calls that happen at compile time.
 ## Rationale based on Carbon's goals
 
 We are attempting to choose a syntax that advances Carbon's goal of having
-[code that is easy to read, understand, and write](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write).
+[code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write).
 This option was chosen since it has the advantage of being very simple and not
 relying on any context, in accordance with the
 [#646: low-context-sensitivity principle](https://github.com/carbon-language/carbon-lang/pull/646).