:+1: 对于这个，我建议将此功能命名为cups ，如茶杯......

@laplix这可能与通用 Unix 打印服务有点混淆。 也+1。

杯子？ 丘比特？ 或者只是Pastebin？

或者只是片段，我知道这不是一个花哨的名字；）

我仍然（见 gogs 问题）认为这应该是一个外部服务。 但是，我们可以将其注入 Gitea 🙂

可选功能：

) 评论区
) 修订（历史）
) 语法高亮，这在 Gist 中甚至不可用
) 过滤和排序

许多 +1 和许多单独创建的关于此提案的问题报告显示了一幅清晰的画面：

gogits/gogs#936

另一方面，实现代码片段应该相当简单。

保留一个名为_snippets （或类似名称）的隐藏仓库，每个片段都是一个文件夹，一个文件夹（或片段）可以包含多个文件。 完毕 ：）

@bkcsoft在 GitHub 上，每个片段都是一个 Git 存储库（但可以包含许多文件）。 但我们可以让它变得不同。

我不知道它应该是 Gitea 的一部分还是一个单独的项目。 如果在 Gitea 中，重用代码会更容易。

无论如何，我们应该记住，很多人（包括我在内）不喜欢 Gists 的 GitHub UI。 我认为我们可以做得更好。 应该有类别或标签来组织要点。 应该很容易找到和搜索现有的 Gists。

在一个 repo中包含所有片段：

优点：

• 易于导入/与您的编辑器同步
• 相当容易实现：trollface：（想想复制粘贴维基代码）

缺点：

• 如果您大量使用片段可能会变慢
• 很难完全删除一个片段（重写历史，永远不好）

Gist UI 确实很烂......有很多需要改进的地方，只是感觉被黑在一起......

IMO 我们应该包含与所述 repo 的片段有关的所有内容（如果是一个，否则我将全部用于子模块或任何跟踪它们的东西......），这包括类别（任何人的文件夹？：trollface :) 和标签

将它作为一个文件保存在 repo 中可以很容易地将它同步到你的编辑器，并且使得搜索变得相当简单🙂

@andreynering我也考虑过标签，认为这是个好主意。
也许将这些标签/类别放在左侧
因此很容易创建和查找特定的粘贴箱：

可能是一个不错的分叉和调整候选者： https ://github.com/defunkt/gist

或者这个， https://github.com/gmarik/Gistie

defunkt/gist是一个与 Gist 对话的命令行工具， gmarik/Gistie是用 Ruby 编写的，两者在这里都不是很相关🙂

首选纯 golang 库。

@lunny @bkcsoft在我的情况下，我发布 Gistie 是为了查看该工具如何在 Gitea 上工作和实施，而不是在 Gitea 中使用工具。

您可以将它与加速服务器一起使用，因此人们不必考虑空间。 默认使用 hastebin.com 并使用 javascript 从客户端发送请求，因此服务器不会受到速率限制。 同时也允许用户使用自己的haste-server。 它可以使用 iframe 来实现。

我今天刚刚发现了一个很棒的工具，我想与您分享： fssnip.net

添加到原始赏金中。 无论如何，就历史和离线修改而言，我认为将每个片段都作为自己的 repo 可能是最好的方法。

顺便说一句，Bountysource 链接似乎已损坏。 这是目前的总数：

关于Gist或我们称之为Cups的一些想法？

1. 一个cup是一个指定的存储库，以便我们可以重用所有旧代码。 然后我们有镜像、分叉、杯子等存储库类型。
2. 每个类型存储库都可以有不同的选项卡（我们将它们存储在 repo_unit 上）。 所以每个存储库都可以将它们的单元加载到选项卡中。
3. 对于cup存储库，只允许文本文件（没有文件夹、没有图像、没有二进制文件），第一个文件的名称也是存储库的名称。 例如tea.go 。 cup存储库主 UI 将显示文件的代码和一些注释。 注释可能在底部或某些代码行上。
   它也有描述或类。
4. 对于cup存储库，创建存储库时只有一个问题。 所有的评论都应该跟在这个 issue 后面，然后我们可以在cup UI 上看到所有的评论。
5. cup存储库可以在/cups/<user_name>/<cup_name>和仪表板顶部菜单上的单独条目中。 所有其他地方都不会显示这种类型的存储库。 但是存储库名称不能在用户的正常存储库上重用。 这个 UI 可能是@ShalokShalom的屏幕截图或任何新想法。 并提供代码搜索，因为我们已将其合并到 v1.3。

看一下要点，可以有几个文件。

@lunny关于3：对于要点，我有时会使用多个文件，所以我认为将其限制为一个可能不适用于某些情况。 此外，也许我们可以不强制执行文件扩展名，而是假设 text/plain，或者检查文件是否为二进制文件，然后只提供原始文件的链接。

编辑： ptman 首先得到它。

pastebin 服务的二进制文件？ 不是一个好主意。

请不要要求文件扩展名，否则您将无法共享生成文件。

@ptman @tboerger @techknowlogick更新了我的评论。

由于有些人不喜欢我们如何将时间跟踪集成到核心中，那么让 pastebins 成为与 giteas api 紧密集成并使用它的存储库来存储粘贴的外部服务呢？
我认为即使是 Githubs pastebin 也是一种外部服务......

@kolaente所以默认是禁用的。 但是作为一个外部服务，它比作为一个内部服务需要更多的工作，因为存储库、问题、评论都准备好了。

两个都？ 那么 Github Gists 与自己的解决方案一起使用吗？
和 Gitpin(s) 的内部名称？

业主编辑：请保持讨论工作安全......

+1

@lunny这个怎么样。 保留存储库_snippets.git然后让外部服务将其用于片段？

编辑：这样我们仍然可以访问评论（一旦实现并合并：trollface:）

或者.snippets.git就像.wiki.git ？ 哪个外部服务适合这样做？

我认为如果我们有一个处理 pastebin 服务的外部服务，我们就不需要为此保留一个存储库。

否则，如果我们在 gitea 中实现 pastebin 服务，我会喜欢保留存储库的想法，因为粘贴通常不是很多，我认为不需要每次都创建存储库，我认为这将是创建一些粘贴时，经过一段时间后存储库过多。

我认为可以使用单个存储库并为每个粘贴创建新分支

有什么理由为什么我们不应该每次粘贴都有一个回购？ 关于 GitHub 的 Gists 最酷的事情之一是它们实际上是可以克隆和提交的完整存储库。

我也这么看，54

+1

一旦可能：我们可以简单地创建一个链接到自定义 pastebin 服务的按钮吗？

这给了我们几个优势： 非常快速的开发和定制。
老实说：
自从我写了这个问题后，我喜欢的语言发生了变化，它的 pastebin 服务甚至支持工具提示和库。

以后仍然可以使用 Gitea 实现，这（好到）零额外的努力？

我不赞成使用外部 pastebin 服务。 我的公司使用 Gitea 的原因是为了安全和内部访问，将它放在内部网络中。 我们不能使用外部服务，否则我们将使用 github 或 bitbucket。 应该努力最终确定他们希望如何在 gitea 中实现它，而不是被垃圾替代品分心

无论如何，在主版本中，您可以将自定义选项卡添加到自定义模板中的外部链接

“外部”不一定意味着“由其他人经营”
模块化也有它的优点...

@ShalokShalom我同意链接可能是第一步，甚至可能只是为了惹恼某人以使事情变得更好

@strk当然，但如果我们只想要模块化而不是集成，为什么我们有问题跟踪？ 发布？ gitosis 提供的以外的任何东西

@lafriks真的吗？ 如何？

@ptman好吧，要集成两者-指向其他页面的链接和自己的解决方案-是模块化的吗？

@lukewatts @strk的想法适合您吗？

@ShalokShalom我希望一旦集成解决方案可用，该链接就会消失

无论如何，通用操作的链接很有帮助。 您可以链接到您的项目页面等。

内部解决方案将缺乏对我很重要的功能。

语法突出显示处于非常早期的状态。

这比Tooltips怎么样？

@ShalokShalom是的，请参阅https://docs.gitea.io/en-us/customizing-gitea/部分“添加链接和选项卡”（这是在 #3308 中添加的）

非常感谢^_^

@ShalokShalom只要指向外部服务的链接不会成为将最终解决方案放在长手指上的借口，我想自定义链接就可以了..
如果我知道 Go，我会提供帮助，而不仅仅是抱怨。 我赞成任何能让我们在合理的时间内更接近一个好的最终解决方案的方法。

您也可以链接到内部服务，只要您自己托管它？

对我来说，像 GitHub gists 之类的东西都会做，但如果可以做出一些改进，比如
标签/类别
甚至是中等/博客风格的格式，这显然是一个加分项

我认为在没有太多复杂性的情况下融入 gitea 最适合 gitea 哲学

一个无痛的自托管 Git 服务。

注意到使用 BitTorrent、IPFS 或 privEOS 去中心化的机会。 我喜欢拥有数据，但是为此拥有更多联合的东西将是一个很好的峰值。

所以这个请求现在已经超过 2 年了。 我想知道这方面是否取得了任何进展？

没有人在这方面工作。

由于我们现在有 oauth 支持，我们也许可以构建一些外部的东西。

是的，我认为@ShalokShalom的形象很漂亮https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny这是Flarum。

我喜欢删除用户的想法。
并命名它们为杯子，就像 lunny 提议的那样。 ^^

于是分发了杯子。 :心: - :心:
分享一些杯子，让我们做一个茶话会。 :D

为此目的投入一些库（在Go中）：

非常简单的核心： https ://github.com/dyne/binnit
漂亮（&）完整： https ://github.com/andreimarcu/linx-server
还有一个： https ://github.com/Parimer/spectre

还有一个已经分发的：

开发停滞，基于 IPFS： https ://github.com/beardog108/seedbin

根据 Ghost 的建议，我找到了一个完全去中心化（分布式）的 Git 托管解决方案，他们可能有兴趣合作。 我今天可能会问他们，如果你没事的话： https ://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

有这方面的更新吗？
额外的维护使我的工作场所无法提供外部服务，但我们可以使用 gitea cups 服务。
这个功能对我来说是一个巨大的优势:)

我认为这应该在 Gitea 的路线图中。

是的，请添加这个！

也很想看到这个

是的，请添加这个！

也很想看到这个

请使用情绪来进行问题启动评论：

它不会通过电子邮件打扰许多订阅者：

它还有更多功能：

我非常喜欢 Sips 的名字（与 (gi)Tea 相关）作为要点。 :) Cups 也很好，但让我想起了全尺寸的存储库。

我有一个未完成的公关名称它杯子

常见的 Unix 打印系统？ 抱歉:笑:

@Mikaela哈！ 没想到这么用。

@lunny我浏览了 PR，看看是否有什么我可以帮助或复制的东西，但我没有看到任何与 pastebin、bin、paste、cup 或 cups 匹配的东西？ 如果已经有一些事情正在进行中，我很乐意帮助推动它。 或者即使没有，就此而言。 只是不想重复努力。

Arch 使用 PKGBUILD，与 Apple 的 pkgbuild 相反。
杯子而不是杯子应该没问题。 我看不到挣扎

任何新闻？

至于名字

如果我们想让它熟悉，它应该是gists 。

如果我们希望它具有品牌价值，对我来说， sips比cups更有意义。 但是，我反对将这样的通用功能品牌化。

Gitlab 使用品牌术语

在 Gitlab 的情况下，他们选择了“合并请求”而不是“拉取请求”，如果你考虑一下原始 Github 上的“拉取请求”与它的“自动合并”功能的历史背景，这是有道理的后来演变成。

但是，如果他们不做一点谷歌关键字规划师研究并发现使用“合并请求”这个词给了他们某种 SEO 优势，我会感到惊讶。

新的用户体验

正如我所说，我个人认为给它一个品牌名称没有多大价值。

作为一个新用户，这会让我翻白眼想：

为什么每个人都必须叫同一个东西不同的名字，呃

最后的想法

gist不是商标，它很熟悉，也很有意义

如果我们不使用gist来熟悉，我建议我们使用 Google Keyword Planner 故意选择一个名称，以发现人们在到达“pastebin”、“postbin”时寻找的熟悉术语， “要点”等

我同意合并请求，这对我来说更有意义。

我个人喜欢使用自己的名字的想法，老实说，对于 google 索引，只需在文档中这样写就足够了：

“Cups 是一种保存笔记的解决方案，类似于 GithubGist 和 Pastebin 提供的。”

为什么品牌很重要

自己的名字很有意义，因为它们有助于识别 - 这就是为什么我们都没有相同的名字。

公司将其收入的一半左右用于品牌建设，百事可乐说“我们不需要自己的名字，就叫它可乐”是荒谬的。

另外，让我们谈谈独特的功能。

只是我的生活经验：当你谈论 GitHub 时，你应该使用 PR（Pull Requests）（或Public Relations ？），当你谈论 GitLab 时——你应该使用 MR（Merge Requests）。 如果有人不熟悉 GitLab，例如，它可能是这样的：

— 请打开 MR。
- 先生？
— 是的，就像... GitHub 中的 PR。

有时，特别是如果你比另一个更喜欢一个，你可能会写一个错误，比如：

— 我已经为你的 GitHub 项目打开了 MR。
- 先生？
——哦，对不起，公关。

片段与要点也是如此。

您可以随心所欲地调用 Gitea，但使用新名称会使术语变得臃肿。

为什么不是 gits？ 说起来容易，它指的是 gitea，但是现在当我写的时候..突然......上帝该死..我更喜欢 gitbits..有点喜欢花絮。
嗯..好吧，如果有这样的插件，那就太好了！ 不管它叫什么。 顺便感谢您开发 gitea。 可爱的软件。 当我可以直接在 Gitea 中编辑我的服务器/服务器配置文件时，我还想要一个功能。 带有版本历史记录和一切。

就个人而言，我不在乎你怎么称呼它。 我宁愿首先关注实施。

今天，我意识到单个脚本不应该出现在我要共享的脚本仓库中，但我想以与从其他机器检索其他脚本相同的方式检索该脚本。 做一个完整的回购是愚蠢的。

这让我认为私人 gists 是存储、检索和跟踪机密文件的好方法。

当我在这里时，我会插话名字。 坦率地说，到目前为止我不喜欢任何东西。 我建议将服务命名为 Gistea，并将片段命名为 Leaf。 Gistea 是一个独特的关键字，但仍可识别为 Gitea 的主旨，而叶子是一个聪明而吸引人的类比。

我特别不喜欢“杯子”。 让我想起了玛吉辛普森的某个场景。 “杯子……你能拼出那个吗？”

我建议将服务命名为 Gistea，并将片段命名为 Leaf。

我喜欢这样 :innocent:

我很想在这个评论中有类似模型的东西。 每当我学习新东西时，我总是觉得我没有一个放置非正式信息和笔记的好地方，尤其是那些不适合特定项目的东西。

作为一个实际用例，我最近一直在学习 Drone (CI)。 因为它适用于任何项目，所以我没有什么地方可以记录想法、示例、提醒、提示等。我没有足够的知识来为自己的指南创建一个文档站点，即使我这样做了，我也发现可能会分散注意力。 我可以创建一个项目只是为了使用 Wiki，但 Wiki 需要一个过于正式的结构，无法收集一堆随机的想法和想法。

现在我已经确定了一个单独的项目，我滥用问题跟踪器来获取非正式笔记，只是因为我可以给它们添加标签。 一般来说，我尝试通过使用issue --> wiki --> formal docs来改进文档，但这对于 Linux CLI 提示等小事情并不适用。像链接评论中的设置这样我可以对事物进行分类和标记太棒了。 我会用它一吨。

https://github.com/fragmenta/fragmenta-cms
有 postgresql golang 位。
Mongodb golang bits mysql, sylla/Cas​​sandra。
然而他们，众多的 pastebin 服务，
（配置文件：gist、pastbin..、wetpaste 等）

https://secrethub.io/ ，将 api 密钥或秘密分发到盒子比 gists 更好。
Valt.io 或类似的秘密保管服务....

My.dev.box 与 hacked.box.someplace.else
uid 密码，dns ok...
如果不在家庭位置或托管服务器
杀了..它现在。
可以批准盒子与安全要点。

我完全想要私人 gist 我的 api 翻转密钥私人...
偶然在团队开发人员的博客上写了一些脏东西...

OSINT INTELLIGENCE，可以揭露我所谓的隐藏服务。 即要点..

Python OSINT 工具、您的车牌、您的地址、手机、运营商等。
Github/gitlab/etc 用于密钥 api ，嵌入密码....

所以过滤块字符串，即密码 api 密钥
也可能证明理智。

用 go 编写的一种替代方法： https ://dev.sigpipe.me/dashie/git.txt