GitHub 的“永久链接”机器人悄悄地毁了我的帖子的意思

贡献 功能
1

大约一年前，我在 GitHub 的 Discourse 实例上发布了一篇帖子（链接），其中包含大量形如 <span>https</span>://github.com/OWNER/REPO/tree/BRANCH/path 的 URL，旨在讨论 GitHub.com 如何处理此类 URL。我的帖子随即收到了一条系统自动生成的编辑，提示“Github 链接已被替换为永久链接”，这似乎来自 discourse-github 插件。虽然在引用特定代码的常见情况下，将分支名称替换为指向当前提交 ID 的永久链接可能是一项有用的功能，但在讨论 GitHub URL 处理机制这一特殊场景下，该编辑破坏了我帖子的原意。我有幸立即发现了这一机器人编辑，在与该机器人进行了多轮对抗后，最终找到了一个变通方法：添加 <span> 标签以阻止机器人的模式匹配，如下所示：

https://github.com/OWNER/REPO/tree/<span>BRANCH</span>/PATH

但其他作者可能不会注意到机器人的编辑，从而导致其帖子让读者感到困惑。

避免对特定帖子进行不必要的 GitHub 永久链接编辑的最佳解决方案是什么？总体而言，我认为机器人进行可能破坏帖子内容的自动编辑是不恰当的。更安全的做法是：(1) 在帖子保存时询问作者是否应该编辑链接，或者 (2) 让机器人在保留原始链接的同时添加永久链接。（我似乎记得在其他网站上，也许是 Reddit，见过一些机器人会在不删除现有信息的情况下添加信息。）如果 Discourse 维护者认为这些选项过于难看或为适应这种罕见用例而投入的工作量过大，那么其他可选方案可能包括：(3) 在帖子保存后显示一条通知，并提供链接说明作者如何避免此类编辑，具体形式可以是 (a) UI 中的专用横幅，或 (b) 机器人直接在帖子末尾添加的一行文字。

我不确定作者选择退出此类编辑的最合理设计是什么。discourse-github 插件基于链接目标的站外排除设置似乎并不适合此目的。或许我目前使用 <span> 标签的变通方法已经足够。即使 Discourse 本身不做任何更改，我也希望这篇帖子能让注意到该问题的作者更容易发现这一变通方法。

注意：我此前曾在 GitHub 论坛上 提出过此问题，因为我原以为“永久链接”机器人是 GitHub 实例特有的，但那里的评论者提醒我，这是 Discourse 的通用功能，因此我在这里提出此问题。

感谢您的关注！

2 个赞
2

我认为这是一个很好的功能，因为人们经常粘贴指向 master 的链接，而这些链接几乎总会随时间推移而过时。不过，仍然应该允许有意粘贴指向分支的链接，因为这样做有很多正当理由。此外，该功能总体上似乎有些问题：它重写了本不该重写的内容，却没有解析本应解析的内容。

以下是一些可作为测试用例的示例，用于修复该问题：

  1. 仅通过粘贴 URL 生成的纯文本链接。我期望此类链接会被重写，确实如此：subdomain-static/forums-enhancements.js at master · ClassicPress/subdomain-static · GitHub
  2. 格式为 [url](url) 的 Markdown 链接。我期望此类链接不被重写，因为我已明确指定了文本和 URL。然而，实际情况是链接文本被重写，而链接 URL 未被重写。这是错误的：https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  3. 用反引号包裹的 URL。这不是链接，不应被重写，但实际却被重写了：https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  4. 位于三反引号代码块中的 URL。这不是链接，不应被重写，但实际却被重写了：
    https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js

我认为只有上述第（1）种情况应该被重写。这将使行为更加可预测，并且仅重写“纯文本”链接。对于使用了特定 Markdown 结构的链接（可视为表达特定意图的一种方式），应保持不变。

1 个赞
3

此功能似乎未在 meta.discourse.org 上启用？

4

FWIW，我不同意：我认为在 (2) 编辑： [text](URL) 的一般情况（称之为 (2a)）下，链接 URL 应与 (1) 以相同方式重写。（我同意当前重写文本而不重写 URL 的行为完全是错误的。）我根据是否认为读者看到 URL 有用或分散注意力来决定是编写 (1) 还是 (2a)，而不是根据链接是否应指向编写时或阅读时的代码版本来决定。当然，我意识到了永久链接的问题，所以当我想要一个永久链接时，我自己就会创建一个。但更普遍地说，如果 Discourse 管理员决定启用永久链接机器人，大概是因为他们认为他们的大多数用户都没有意识到基于分支名称的链接可能会过时，而我不认为使用 Markdown 链接语法在很大程度上表明某个用户意识到了这个问题但希望选择不重写该特定链接。

但我认为我们都在猜测。作为一个高级用户，只要我能根据需要覆盖它，我不太关心默认设置是什么。

5

是的，正是如此。目前没有办法覆盖它。编写 [url](url)（链接文本和 URL 完全相同）肯定是一种向机器人发出信号的方式，表明该链接不应被重写，因为没有其他理由以这种方式编写它。

6

如果你想为链接提供自己的标题，而不是从目标 URL 推断出来，即 [标题](URL)，那么就有理由这样写。为链接提供标题不会表明偏好 URL 重写，因此我同意 @mattmccutchen 的观点，即 1 和 2 在 URL 重写方面应该保持一致。

可以认为标题与 URL 完全匹配是 URL 不应被重写的指示，但如果用户想提供标题并且不希望 URL 被重写，该怎么办？需要有其他方法来指定这一点。

我想到的可能是标题后缀，类似于嵌入式图像的大小调整，尽管我不确定用户将如何发现它。

嵌入式图像可以这样调整大小：
![标题|100x200](URL)

因此，discourse-github 插件可以（假设）查找类似这样的内容：
[标题|github-no-rewrite](URL)

7

啊，我没弄清楚你的 (2) 只指文本和 URL 相同这个特殊情况。我的陈述是针对文本和 URL 可能不相同的普遍情况；我们现在称之为 (2a)。

在情况 (2) 下，我同意重写 URL 而不重写文本，使它们不一致，这很奇怪，但 ISTM 人们同样可以争辩说，如果我们想避免不一致，最好的方法是重写 URL 和文本，而不是两者都不重写。所以我不认为将 (2) 作为选择退出是有说服力的。鉴于我们应该有一个适用于 (2a) 的选择退出，我倾向于让用户为 (2) 使用相同的选择退出，而不是使设计复杂化。（我认为这可能是 Simon Manning 的想法？）

8

不确定我是否正确理解了这一点（或者这是否可行），但您能否像在 Inline PDF Previews - #45 by Johani 中那样使用空格转义？这样 [ text]( url) 就不会重写文本或 URL，而其他任何内容都会自动更改？

9

此版本应保持不变，不应重写，让我看看：

https://github.com/correctcomputation/checkedc-clang/blob/master-post-microsoft/clang/docs/checkedc/Setup-and-Build.md

写成：

<https://github.com/correctcomputation/checkedc-clang/blob/master-post-microsoft/clang/docs/checkedc/Setup-and-Build.md>
10

这不是一个有效的测试，因为在此 Discourse 实例上完全禁用了 GitHub 永久链接重写。（我想知道如果此功能在“官方”实例上被禁用，这说明了什么 :upside_down_face:）

如果你要将此示例作为 replace_github_non_permalinks.rb / replace_github_non_permalinks_spec.rb 的测试用例来编写，那么我认为你会发现该链接也会被重写。

1 个赞