：+1：これについては、お茶のカップのように、この機能にカップという名前を付けることをお勧めします。

@laplixこれは、Common Unix PrintingServiceとは少し混乱するかもしれません。 また、+ 1も。

カップ？ キューピ？ または単にペーストビン？

または単にスニペット、私はそれが派手な名前ではないことを知っています;）

私はまだ（gogsの問題を参照）これは外部サービスであるべきだと思います。 ただし、Giteaに注入可能にすることはできます🙂

オプション機能：

）コメントセクション
）改訂（履歴）
）構文の強調表示。これはGistでも使用できません。
）フィルターと並べ替え

この提案に関する多くの+1と個別に作成された問題レポートは、明確な状況を示しています。

gogits / gogs＃936

一方、スニペットの実装はかなり簡単なはずです。

_snippets （または同様のもの）と呼ばれる非表示のリポジトリを保持します。各スニペットはフォルダーであり、フォルダー（またはスニペット）には複数のファイルを含めることができます。 終わり ：）

@bkcsoft GitHubでは、各スニペットはGitリポジトリです（ただし、多くのファイルを含めることができます）。 しかし、私たちはそれを変えることができます。

それがGiteaの一部なのか、それとも別のプロジェクトなのかわかりません。 Giteaの場合、コードを再利用する方が簡単です。

とにかく、多くの人（私を含む）がGistsのGitHubUIを嫌うことを覚えておく必要があります。 私たちはそれをもっとうまくやれると思います。 要旨を整理するためのカテゴリまたはタグが必要です。 既存の要点を簡単に見つけて検索できるはずです。

1つのリポジトリにすべてのスニペットが含まれています：

長所：

• エディターとのインポート/同期が簡単
• 実装はかなり簡単です：trollface ：（コピーして貼り付けるwikiコードを考えてください）

短所：

• スニペットを頻繁に使用すると遅くなる可能性があります
• スニペットを完全に削除するのは難しい（履歴を書き換える、決していいことはない）

要旨のUIは確かにひどいです...改善すべき点がたくさんあり、一緒にハッキングされたように感じます...

IMOは、レポへのスニペットに関するすべてを含める必要があります（単一の場合、そうでない場合は、サブモジュールまたはそれらを追跡するためにすべてがダウンしています...）、これにはカテゴリ（フォルダは誰ですか？：trollface :)とタグが含まれます

リポジトリにファイルとして含めると、エディターとの同期も簡単になり、検索もかなり簡単になります🙂

@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を使用してクライアントからリクエストを送信すると、サーバーのレート制限がなくなります。 ただし、ユーザーが独自の速攻サーバーを使用できるようにすることもできます。 iframeを使用して実装できます。

今日、あなたと共有したい素晴らしいツールを見つけました： fssnip.net

元の報奨金に追加されました。 とにかく、私は、各スニペットを独自のリポジトリとして持つことが、履歴とオフラインでの変更に関する限り、おそらくそれを行うための最も良い方法だと思います。

ちなみに、Bountysourceのリンクは壊れているようです。 現在の合計は次のとおりです。

Gistに関するいくつかのアイデア、またはそれをCupsと呼びますか？

1. 1つのcupは指定リポジトリであるため、古いコードをすべて再利用できます。 次に、ミラーリング、フォーク、カップなどのリポジトリタイプを作成しました。
2. タイプリポジトリごとに異なるタブを設定できます（repo_unitに保存します）。 したがって、すべてのリポジトリがユニットをタブにロードできます。
3. cupリポジトリの場合、許可されるのはテキストファイルのみ（フォルダ、イメージ、バイナリファイルなし）であり、最初のファイルの名前はリポジトリの名前でもあります。 たとえば、 tea.go 。 cupリポジトリのメインUIには、ファイルのコードといくつかのコメントが表示されます。 コメントは、下部またはコード行にある可能性があります。
   また、説明やクラスもあります。
4. cupリポジトリの場合、リポジトリを作成するときに問題が1つだけあります。 すべてのコメントはこの問題の後に続く必要があります。そうすれば、 cup UIにすべてのコメントを表示できます。
5. cupリポジトリは、 /cups/<user_name>/<cup_name>にあり、ダッシュボードのトップメニューに別のエントリがある可能性があります。 他のすべての場所では、このタイプのリポジトリは表示されません。 しかし、リポジトリ名はユーザーの通常のリポジトリで再利用できませんでした。 このUIは、 @ ShalokShalomのスクリーンショットや新しいアイデアである可能性があります。 v1.3でマージしたので、コード検索を提供します。

要点を見てください。いくつかのファイルが存在する可能性があります。

@lunny 3に関して：要点では、複数のファイルを使用することがあるので、1つに制限しても機能しない場合があると思います。 また、ファイル拡張子を強制する代わりに、text / plainを想定するか、ファイルがバイナリファイルであるかどうかを確認してから、rawファイルへのリンクを提供することもできます。

編集：ptmanが最初にそれに到達しました。

ペーストビンサービスのバイナリファイル？ 良い考えではありません。

ファイル拡張子は必要ありません。そうしないと、makefileを共有できません。

@ptman @ tboerger @ techknowlogickが私のコメントを更新しました。

タイムトラッキングをコアに統合する方法が気に入らなかった人もいるので、ペーストビンをgiteas apiと緊密に統合し、そのリポジトリを使用してペーストを保存する外部サービスを作成するのはどうでしょうか。
Githubsのペーストビンでさえ一種の外部サービスだと思います...

@kolaenteなので、デフォルトは無効になっています。 ただし、リポジトリ、問題、コメントはすべて準備ができているため、外部サービスとしては、内部サービスよりも多くの作業が必要になります。

両方？ では、Githubは独自のソリューションと一緒に要点を説明しますか？
そして、内部名のGitpin（s）？

所有者編集：議論を仕事のために安全に保ってください...

+1

@lunnyこれはどうですか。 リポジトリ_snippets.gitを予約してから、外部サービスにそれをスニペットに使用させますか？

編集：そうすれば、コメントにアクセスできます（実装されてマージされた後：trollface :)

または.snippets.git .wiki.git ？ そして、どの外部サービスがそれを行うのに適していますか？

ペーストビンサービスを処理する外部サービスがあれば、このためのリポジトリを予約する必要はないと思います。

それ以外の場合、geteaでpastebinサービスを実装する場合は、予約済みのリポジトリのアイデアが大好きです。通常、ペーストはそれほど多くないので、毎回リポジトリを作成する必要はないと思います。これは次のようになります。いくつかのペーストを作成するときに、リポジトリが多すぎると時間がかかります。

単一のリポジトリを使用して、貼り付けごとに新しいブランチを使用できると思います

ペーストごとにレポを使用するべきではない理由は何ですか？ GitHubのGistsの最も優れた点の1つは、実際にはクローンを作成してコミットできる完全なリポジトリであるということです。

私もそう思います、54

+1

可能であれば：カスタムペーストビンサービスにリンクするボタンを簡単に作成できますか？

これにより、いくつかの利点が得られます。非常に迅速な開発とカスタマイズ。
実を言うと：
私がこの問題を書いたので、私の好みの言語変更を行いました、そしてそのペーストビンサービスはツールチップとライブラリさえサポートします。

Giteaの実装は後でまだ可能であり、これは（同じくらい）追加の労力がゼロですか？

私は外部のペーストビンサービスに賛成していません。 私の会社がGiteaを使用する理由は、セキュリティと内部アクセスのために、Giteaを内部ネットワーク内に配置するためです。 外部サービスを使用することはできません。そうしないと、githubまたはbitbucketを使用することになります。 がらくたの代替案に気を取られないように、彼らがどのようにそれをgiteaに実装したいかを最終決定することに努力を払う必要があります

とにかくマスターバージョンでは、カスタムテンプレートの外部リンクにカスタムタブを追加できます

「外部」とは、必ずしも「他の誰かによって運営されている」という意味ではありません。
モジュール性にも利点があります...

@ShalokShalomリンクが最初のステップになる可能性があることに同意します。おそらく、何かを改善するのに十分な人を困らせるためだけかもしれません。

@strk確かに、しかし、モジュール性だけが必要で、統合が必要ない場合、なぜ問題追跡があるのですか？ リリース？ gitosisが提供するもの以外のもの

@lafriks本当に？ どのように？

@ptmanええと、両方を統合するために-他のページへのリンクと独自のソリューション-モジュール式ですか？

@lukewatts @strkのアイデアはあなたにとって良いですか？

@ShalokShalom統合ソリューションが利用可能になると、リンクがなくなると思います

とにかく、一般的なアクションのリンクは役に立ちます。 プロジェクトページなどにリンクできます。

そして、内部ソリューションには、私にとって重要な機能が欠けています。

構文の強調表示は非常に初期の状態です。

ツールチップについてはどうですか？

@ShalokShalomはい、 https： //docs.gitea.io/en-us/customizing-gitea/セクション「リンクとタブの追加」を参照してください（これは＃3308で追加されました）

どうもありがとう^ _ ^

@ShalokShalom外部サービスへのリンクが長い指に最終的な解決策を置く言い訳にならない限り、カスタムリンクで問題ないと思います。
Goを知っていれば、ただ噛むのではなく、助けたいと思います。 私は、妥当な時間内に優れた最終的なソリューションに近づくことができるものすべてに賛成です。

自分でホストしている限り、内部サービスにリンクすることもできますか？

私にとってはGitHubの要点のようなものなら何でもできますが、いくつかの改善を行うことができれば
タグ/カテゴリ
または明らかにプラスになるミディアム/ブログスタイルのフォーマット

giteasの哲学には、それほど複雑なことなくgiteaに統合するのが最善だと思います

痛みのないセルフホストのGitサービス。

BitTorrent、IPFS、またはprivEOSを使用して分散化する機会に注目してください。 私はデータで所有するのが好きですが、これのためにもっと連合されたものを持っていることは見るのに良いスパイクになるでしょう。

したがって、このリクエストは2年以上前のものになりました。 これに関して何か進展があったのだろうか？

誰もこれに取り組んでいません。

現在、oauthがサポートされているため、外部のものを構築できる可能性があります。

はい、 @ ShalokShalomの画像は美しいと思いますhttps://github.com/go-gitea/gitea/issues/693#issuecomment-274277781

@lunnyこれはFlarumです。

削除されたユーザーのアイデアが大好きです。
そして、ラニーが提案したように、それらにもカップという名前を付けます。 ^^

だから分散カップ。 ：heart：-：heart：
いくつかのカップを共有して、お茶会を作りましょう。 ：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カップサービスは使用できます。
この機能は私にとって大きなプラスになるでしょう:)

これはGiteaのロードマップに含まれるべきだと思います。

はい、これを追加してください！

これも見たいです

はい、これを追加してください！

これも見たいです

問題のスターターコメントに感情を使用してください：

それは電子メールを介して多くの購読者を邪魔することはありません：

そしてそれはより多くの機能を持っています：

私は要点の名前Sips（（gi）Teaに関連して）がとても好きです。 :)カップも良いですが、フルサイズのリポジトリを思い起こさせます。

私はそれがカップする未完成のPR名を持っています

一般的なUnix印刷システム？ すみません：笑い：

@ミカエラハァッ！ その使用法についても考えていませんでした。

@lunny PRを調べて、手伝ったりリフしたりできるものがあるかどうかを確認しましたが、ペーストビン、ビン、ペースト、カップ、またはカップに一致するものは見つかりませんでしたか？ すでに何かが進行中の場合は、私はそれを前進させるのを手伝って喜んでいます。 または、ない場合でも、そのことについて。 努力を繰り返したくないだけです。

Archは、Appleのpkgbuildではなく、PKGBUILDを使用しています。
CUPSの代わりにカップで十分です。 苦労は見られない

連絡あった？

名前は

使い慣れたものにする場合は、 gistsにする必要があります。

ブランディング可能にしたい場合は、 cupsよりも$ sipsの方が理にかなっています。 しかし、私はそのような一般的な機能をブランド化することに反対します。

Gitlabはブランド用語を使用しています

Gitlabの場合、「プルリクエスト」ではなく「マージリクエスト」を選択しました。これは、元のGithubでの「プルリクエスト」と「自動マージ」機能の履歴コンテキストを考慮すると意味があります。後に進化しました。

しかし、彼らがGoogleキーワードプランナーの調査を少しも行わず、「マージリクエスト」という用語を使用すると、ある種のSEOの利点が得られることを発見した場合は驚きます。

新しいユーザーエクスペリエンス

私が言ったように、私はそれにブランド名を付けることにあまり価値がないと個人的に見ています。

新しいユーザーとして、それは私が目を転がして考えさせるようなものになるでしょう：

なぜ誰もが同じことを別の名前で呼ばなければならないのですか

最終的な考え

gistは商標ではなく、なじみがあり、理にかなっています

なじみのあるgistを使用しない場合は、Googleキーワードプランナーを使用して意図的に名前を選択し、「pastebin」、「postbin」、 「要点」など

私はマージリクエストに同意します。私にはもっと理にかなっています。

私は個人的に自分の名前を使用するというアイデアが大好きです。正直なところ、グーグルインデックスの場合は、ドキュメントで次のように表現するだけで十分だと思います。

「カップはメモを保存するためのソリューションであり、GithubGistとPastebinが提供するものに似ています。」

ブランディングが重要な理由

自分の名前は識別に役立つので意味があります-それが私たち全員が同じ名前を持っていない理由です。

企業は収入の約半分をブランディングに投資しています。ペプシは「自分の名前は必要ありません。単にコーラと呼んでください」と言っているのはばかげています。

また、独自の機能についてもお話ししましょう。

私の人生経験：GitHubについて話しているときは、PR（プルリクエスト）（または広報？）を使用する必要があります。GitLabについて話しているときは、MR（マージリクエスト）を使用する必要があります。 たとえば、誰かがGitLabに慣れていない場合は、次のようになります。

—MRを開いてください。
- 氏？
—ええ、のように…GitHubのPR。

そして時々、特にあなたがお互いを好きなら、あなたは次のような間違いを書くことができます：

—GitHubプロジェクト用にMRを開きました。
- 氏？
—ああ、すみません、PR。

スニペットと要点についても同じです。

好きなようにGiteaのものを呼び出すことができますが、新しい名前を使用すると、用語が肥大化します。

なぜgitsではないのですか？ 言うのは簡単ですが、それはgiteaを指しますが、今私が書いているとき..突然...神は堕落します..私はgitbitsの方が好きです..少しtidbitsのようです。
うーん..まあそのようなプラグインが来たらそれは甘いでしょう！ それが呼ばれるものは何でも。 ちなみにgiteaを開発していただきありがとうございます。 素敵なソフトウェア。 また、Giteaでサーバー/サーバー構成ファイルを直接編集できる機能が必要です。 バージョン履歴とすべて。

個人的には、あなたがそれを何と呼んでもかまいません。 むしろ、最初に実装に焦点を当てたいと思います。

今日、共有しようとしているスクリプトのリポジトリに1つのスクリプトを含めるべきではないことに気付きましたが、他のマシンから他のスクリプトを取得するのと同じ方法でそのスクリプトを取得したいと思いました。 リポジトリ全体を作成するのはばかげています。

そのため、秘密のファイルを保存、取得、追跡するには、プライベートの要点が良い方法だと思います。

ここにいる間、名前をチャイムします。 率直に言って、私は今のところ好きではありません。 サービスにGisteaとスニペットにLeafという名前を付けることをお勧めします。 Gisteaはユニークなキーワードですが、Giteaの要点として認識されており、葉は巧妙で魅力的なアナロジーです。

私は特に「カップ」が好きではありません。 あるマージシンプソンのシーンを思い出します。 「カップ...それを綴ってもらえますか？」

サービスにGisteaとスニペットにLeafという名前を付けることをお勧めします。

私はそれが好きです：innocent：

このコメントのモックアップのようなものが欲しいです。 何か新しいことを学んでいるときはいつでも、特に特定のプロジェクトに当てはまらないものについては、非公式の情報やメモを入れるのに適した場所がないように感じます。

実際のユースケースとして、私は最近ドローン（CI）の学習に取り組んでいます。 それはどのプロジェクトにも当てはまるので、アイデア、例、リマインダー、ヒントなどを文書化するのに最適な場所はありません。自分のガイドラインの文書化サイトを開始するのに十分な知識がありません。気が散ることがあります。 Wikiを使用するだけでプロジェクトを作成することもできますが、Wikiには、ランダムな考えやアイデアをまとめるには形式的すぎる構造が必要です。

今、私は別のプロジェクトに落ち着きました。そこでは、ラベルを追加できるという理由だけで、課題追跡システムを非公式のメモに悪用しています。 一般的に、私はissue --> wiki --> formal docsを使用してドキュメントを進化させようとしますが、LinuxCLIのヒントなどの小さなものにはうまく機能しません。リンクされたコメントのような設定で分類してタグを付けることができます素晴らしいでしょう。 私はそれを1トン使用します。

https://github.com/fragmenta/fragmenta-cms
postgresqlgolangビットがあります。
Mongodb golangビットmysql、sylla / Cassandra。
しかし、それら、多数のペーストビンサービス、
（設定ファイル：gist、pastbin ..、wetpasteなど）

https://secrethub.io/ 、要点よりもAPIキーまたはシークレットをボックスに配布する方が少し優れています。
Valt.ioまたは同様の秘密の保管サービス...

My.dev.box、vs hacked.box.someplace.else
Uidパスワード、DNS OK..。
自宅の場所にない場合、つまりホスティングサーバーにない場合
殺す..今それ。
セキュリティのためにボックスと要点を比較できます。

私は完全にプライベート要点私のAPIフリッピングキープライベートをワナします...
チーム開発者のブログに偶然にいくつかのスマックを持っています...

OSINT INTELLIGENCEは、私の想定される隠されたサービスのマスクを解除できます。 つまり、要点..

Python OSINTツール、ナンバープレート、住所、携帯電話、携帯電話会社など。
キーAPIのGithub / gitlab / etc、埋め込みパスワード...。

したがって、ブロック文字列、つまりパスワードAPIキーをフィルタリングします
SANEを証明するかもしれません。

goで書かれた1つの代替案： https ：//dev.sigpipe.me/dashie/git.txt