:+1: Für dieses hier würde ich vorschlagen, dieses Feature Tassen ,, wie in Teetassen zu nennen ....

@laplix Das könnte mit dem Common Unix Printing Service etwas verwirrend sein. Auch +1.

Becher? Tasse? Oder einfach Pastebin?

Oder nur Schnipsel, ich weiß, es ist kein ausgefallener Name ;)

Ich denke immer noch (siehe Gogs-Problem), dass dies ein externer Dienst sein sollte. Wir könnten es jedoch in Gitea injizierbar machen 🙂

Optionale Funktionen:

) Kommentarbereich
) Revisionen (Geschichte)
) Syntaxhervorhebung, die nicht einmal in Gist verfügbar ist
) Filtern und Sortieren

Viele +1 und viele separat erstellte Problemberichte zu diesem Vorschlag zeigen ein klares Bild:

gogits/gogs#936

Andererseits sollte es ziemlich einfach sein, Snippets zu implementieren.

Bewahren Sie ein verstecktes Repo namens _snippets (oder ähnlich) auf, jedes Snippet ist ein Ordner, ein Ordner (oder Snippet) kann mehrere Dateien enthalten. Getan :)

@bkcsoft Auf GitHub ist jedes Snippet ein Git-Repo (kann aber viele Dateien enthalten). Aber wir können es anders machen.

Ich weiß nicht, ob es Teil von Gitea oder ein separates Projekt sein sollte. In Gitea wäre es einfacher, Code wiederzuverwenden.

Wie auch immer, wir sollten bedenken, dass viele Leute (mich eingeschlossen) die GitHub-Benutzeroberfläche für Gists nicht mögen. Ich denke, wir können es besser machen. Es sollte Kategorien oder Tags geben, um Gists zu organisieren. Es sollte einfach sein, vorhandene Gists zu finden und danach zu suchen.

Enthält alle Snippets in einem Repo :

Vorteile:

• Einfach zu importieren/mit Ihrem Editor zu synchronisieren
• Ziemlich einfach zu implementieren :trollface: (denken Sie an den Wiki-Code zum Kopieren und Einfügen)

Nachteile:

• Kann langsam werden, wenn Sie häufig Snippets verwenden
• Schwierig, ein Snippet vollständig zu entfernen (Verlauf neu schreiben, nie nett)

Gist UI ist in der Tat scheiße ... viel zu verbessern, fühlt sich einfach zusammengehackt an ...

Meiner Meinung nach sollten wir alles in Bezug auf Snippets zu diesem Repo enthalten (wenn es ein einzelnes ist, sonst bin ich ganz auf Submodule oder was auch immer angewiesen, um sie zu verfolgen ...), dazu gehören Kategorien (Ordner irgendjemand? :trollface:) und Tags

Wenn Sie das als Datei im Repo haben, können Sie es auch ganz einfach mit Ihrem Editor synchronisieren und Suchen ziemlich einfach durchführen 🙂

@andreynering Ich habe auch über Tags nachgedacht, halte das für eine gute Idee.
Vielleicht platzieren Sie diese Tags/Kategorien auf der linken Seite
So ist es einfach, bestimmte Pastebins zu erstellen und zu finden:

Kann ein netter Kandidat zum Forken und Anpassen sein: https://github.com/defunkt/gist

Oder hier, https://github.com/gmarik/Gistie

defunkt/gist ist ein Befehlszeilentool, um mit Gist zu sprechen, gmarik/Gistie ist in Ruby geschrieben, beide sind hier nicht sehr relevant 🙂

Eine reine Golang-Bibliothek wird bevorzugt.

@lunny @bkcsoft In meinem Fall poste ich Gistie als Option, um zu sehen, wie dieses Tool funktioniert und auf Gitea implementiert wird, nicht um ein Tool in Gitea zu verwenden.

Sie könnten es mit einem Eilserver verwenden, sodass die Leute nicht an den Platz denken müssen. Verwenden Sie standardmäßig hastebin.com und senden Sie die Anfragen vom Client mit Javascript, damit der Server nicht ratenbegrenzt ist. Erlauben Sie Benutzern aber auch, ihren eigenen Haste-Server zu verwenden. Es könnte mit einem Iframe implementiert werden.

Ich habe heute ein großartiges Tool gefunden, das ich mit Ihnen teilen möchte: fssnip.net

Wird dem ursprünglichen Kopfgeld hinzugefügt. Wie auch immer, ich denke, dass es wahrscheinlich der beste Weg ist, jedes Snippet als eigenes Repo zu haben, was den Verlauf und die Offline-Änderung angeht.

Der Bountysource-Link scheint übrigens defekt zu sein. Hier die aktuelle Summe:

Einige Ideen zu Gist oder wir nennen es Cups ?

1. Ein cup ist ein bestimmtes Repository, damit wir alle alten Codes wiederverwenden können. Dann haben wir gespiegelte, gegabelte, Cups usw. Repository-Typen.
2. Jeder Repository-Typ kann verschiedene Registerkarten haben (wir speichern sie auf repo_unit). So konnte jedes Repository seine Units in Tabs laden.
3. Für cup Repositories sind nur Textdateien erlaubt (keine Ordner, keine Bilder, keine Binärdateien) und der Name der ersten Datei ist auch der Name des Repositorys. Zum Beispiel tea.go . Die Hauptbenutzeroberfläche des cup -Repositorys zeigt den Code der Datei und einige Kommentare. Der Kommentar könnte unten oder in einer Codezeile stehen.
   Es hat auch eine Beschreibung oder vielleicht Klassen.
4. Für cup Repositories gibt es nur ein Problem, wenn das Repository erstellt wird. Alle Kommentare sollten diesem Problem folgen, dann können wir alle Kommentare auf der Benutzeroberfläche cup sehen.
5. cup Repositories könnten sich in /cups/<user_name>/<cup_name> und einem separaten Eintrag im Hauptmenü des Dashboards befinden. Alle anderen Orte zeigen diesen Repository-Typ nicht an. Der Repository-Name konnte jedoch nicht im normalen Repository des Benutzers wiederverwendet werden. Diese Benutzeroberfläche könnte die Screenshots von @ShalokShalom oder eine neue Idee sein. und stellen Sie eine Codesuche bereit, da wir sie auf v1.3 zusammengeführt haben.

Schauen Sie sich die Gists an, es können mehrere Dateien vorhanden sein.

@lunny In Bezug auf 3: Bei Gists verwende ich manchmal mehrere Dateien, daher denke ich, dass die Beschränkung auf eine in einigen Fällen möglicherweise nicht funktioniert. Anstatt eine Dateierweiterung zu erzwingen, könnten wir vielleicht auch entweder Text/Plain annehmen oder prüfen, ob die Datei eine Binärdatei ist, und dann einfach einen Link zur Rohdatei bereitstellen.

Bearbeiten: ptman kam zuerst dazu.

Binärdateien für einen Pastebin-Dienst? Keine gute Idee.

Bitte fordern Sie keine Dateierweiterung an, da Sie sonst kein Makefile teilen können.

@ptman @tboerger @techknowlogick hat meine Kommentare aktualisiert.

Da einige Leute nicht mochten, wie wir die Zeiterfassung in den Kern integriert haben, wie wäre es, Pastebins zu einem externen Dienst zu machen, der sich eng in die Giteas-API integriert und dessen Repositories zum Speichern von Pasten verwendet?
Ich denke, sogar Githubs Pastebin ist eine Art externer Dienst ...

@kolaente , also ist die Standardeinstellung deaktiviert. Aber als externer Dienst wird es mehr Arbeit erfordern als als interner, da Repository, Ausgabe und Kommentar alle bereit sind.

Beide? Also Github Gists zusammen mit einer eigenen Lösung?
Und Gitpin(s) für den internen Namen?

Besitzer EDIT: Bitte halten Sie Diskussionen für die Arbeit sicher ...

+1

@lunny Wie wäre es damit. Reservieren Sie das Repository _snippets.git und lassen Sie es dann vom externen Dienst für Snippets verwenden?

Edit: Auf diese Weise haben wir immer noch Zugriff auf Kommentare (sobald das implementiert und zusammengeführt ist :trollface: )

Oder .snippets.git genau wie .wiki.git ? Und welcher externe Dienst ist dafür geeignet?

Ich denke, wenn wir einen externen Dienst haben, der den Pastebin-Dienst verwaltet, müssen wir dafür kein Repository reservieren.

Andernfalls, wenn wir den Pastebin-Dienst in Gitea implementieren würden, würde ich die Idee eines reservierten Repositorys lieben, da ein Einfügen normalerweise nicht sehr viel ist. Ich sehe nicht die Notwendigkeit, jedes Mal ein Repository zu erstellen, ich denke, das wäre es zu viele Repositories nach einiger Zeit beim Erstellen einiger Pasten.

Ich denke, dass ein einzelnes Repository verwendet werden könnte und ein neuer Zweig für jede Paste

Gibt es einen Grund, warum wir kein Repo pro Paste haben sollten? Eines der coolsten Dinge an den Gists von GitHub ist, dass es sich tatsächlich um vollständige Repos handelt, die geklont und übertragen werden können.

Das sehe ich auch so, 54

+1

Einmal möglich: Können wir einfach eine Schaltfläche erstellen, die auf einen benutzerdefinierten Pastebin-Dienst verweist?

Das bringt uns mehrere Vorteile: Sehr schnelle Entwicklung und Anpassung.
Um ehrlich zu sein:
Seit ich diese Ausgabe geschrieben habe, hat sich meine bevorzugte Sprache geändert und der Pastebin-Dienst unterstützt sogar Tooltips und Bibliotheken.

Eine Gitea-Implementierung ist später noch möglich und das ist (so gut wie) null Mehraufwand?

Ich bin nicht für einen externen Pastebin-Dienst. Der Grund, warum mein Unternehmen Gitea verwendet, ist, es aus Sicherheitsgründen und für den internen Zugriff in einem internen Netzwerk zu haben. Wir können keine externen Dienste verwenden, sonst würden wir Github oder Bitbucket verwenden. Die Mühe sollte darauf verwendet werden, festzulegen, wie sie es in Gitea implementieren möchten, und sich nicht mit Mistalternativen ablenken zu lassen

Wie auch immer, in der Master-Version können Sie benutzerdefinierte Registerkarten zu externen Links in Ihren benutzerdefinierten Vorlagen hinzufügen

"extern" bedeutet nicht unbedingt "von jemand anderem betrieben"
Modularität hat auch ihre Vorteile...

@ShalokShalom Ich stimme zu, dass ein Link ein möglicher erster Schritt wäre, vielleicht sogar nur, um jemanden genug zu ärgern, um etwas besser zu machen

@strk sicher, aber wenn wir nur Modularität und keine Integration wollen, warum haben wir dann die Problemverfolgung? Veröffentlichungen? alles andere als das, was gitosis bietet

@lafriks Wirklich? Wie?

@ptman Nun, um beides zu integrieren - Links zu anderen Seiten und die eigene Lösung - IST modular?

@lukewatts Findest du die Idee von @strk gut?

@ShalokShalom Ich würde erwarten, dass der Link verschwindet, sobald eine integrierte Lösung verfügbar ist

Der Link für generische Aktionen ist trotzdem hilfreich. Sie können auf Ihre Projektseite verlinken und so weiter.

Und der internen Lösung wird die für mich wichtige Funktionalität fehlen.

Die Syntaxhervorhebung befindet sich in einem sehr frühen Stadium.

Wie ist das denn mit Tooltips ?

@ShalokShalom ja, siehe https://docs.gitea.io/en-us/customizing-gitea/ Abschnitt „Adding links and tabs“ (dies wurde in #3308 hinzugefügt)

Vielen Dank ^_^

@ShalokShalom Solange ein Link zu einem externen Dienst keine Entschuldigung dafür ist, die endgültige Lösung auf den langen Finger zu legen, wäre ein benutzerdefinierter Link wohl in Ordnung.
Wenn ich Go wüsste, würde ich helfen, anstatt nur zu meckern. Ich bin für alles, was uns in angemessener Zeit einer guten endgültigen Lösung näher bringt.

Sie können auch auf einen internen Dienst verlinken, solange Sie ihn selbst hosten?

Für mich würde alles wie GitHub Gists tun, aber wenn einige Verbesserungen vorgenommen werden können, wie z
Tags/Kategorien
oder sogar Formatierung im Medium-/Blog-Stil , die offensichtlich ein Plus wäre

Ich denke, die Integration in Gitea ohne viel Komplikation ist das Beste für die Giteas-Philosophie

Ein schmerzloser , selbst gehosteter Git-Dienst.

Hinweis auf die Möglichkeit zur Dezentralisierung mit BitTorrent, IPFS oder privEOS. Ich mag es, Daten zu besitzen, aber etwas föderierter dafür zu haben, wäre eine schöne Spitze zu sehen.

Diese Anfrage ist also jetzt mehr als 2 Jahre alt. Ich frage mich, ob diesbezüglich überhaupt Fortschritte erzielt wurden?

Niemand arbeitet daran.

Da wir jetzt oauth-Unterstützung haben, können wir vielleicht etwas externes bauen.

Ja, ich finde das Bild von @ShalokShalom wunderschön https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny Das ist Flarum.

Ich liebe die Idee des gelöschten Benutzers .
Und ihnen auch Tassen zu benennen, wie Lunny vorgeschlagen hat. ^^

Also Becher verteilt. :Herz Herz:
Verteilt ein paar Tassen und lasst uns eine Teeparty machen. :D

Zu diesem Zweck einige Bibliotheken (in Go) einwerfen:

Sehr einfacher Kern: https://github.com/dyne/binnit
Ziemlich (&) vollständig: https://github.com/andreimarcu/linx-server
Noch eins: https://github.com/Parimer/spectre

Und eine, die bereits verteilt ist:

In der Entwicklung blockiert, IPFS-basiert: https://github.com/beardog108/seedbin

Gemäß dem Vorschlag von Ghost habe ich eine vollständig dezentralisierte (verteilte) Git-Hosting-Lösung gefunden, und sie könnten an einer Zusammenarbeit interessiert sein. Ich könnte sie heute fragen, ob es dir gut geht: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

Gibt es hierzu ein Update?
Der zusätzliche Unterhalt macht externe Dienstleistungen an meinem Arbeitsplatz tabu, aber ein gitea Tassenservice wäre für uns brauchbar.
Diese Funktion wäre ein großes Plus für mich :)

Ich denke, das sollte in der Roadmap von Gitea stehen.

Ja, bitte ergänzen!

Würde das auch gerne sehen

Ja, bitte ergänzen!

Würde das auch gerne sehen

Bitte nutzen Sie die Emotionen für den Kommentar des Issue-Starters:

Es wird viele Abonnenten per E-Mail nicht stören:

Und es hat mehr Funktionen:

Ich mag den Namen Sips (in Bezug auf (gi) Tea) für Gists. :) Cups ist auch gut, erinnert mich aber an Repositories in voller Größe.

Ich habe einen unfertigen PR-Namensbecher

Gemeinsames Unix-Drucksystem? Entschuldigung :lach:

@Mikaela Ha ! Hatte an diese Verwendung noch gar nicht gedacht.

@lunny Ich habe PRs durchgesehen, um zu sehen, ob es etwas gibt, bei dem ich helfen oder davon absehen könnte, und ich habe nichts gefunden, das zu Pastebin, Bin, Paste, Cup oder Cups passt? Ich helfe gerne weiter, wenn schon etwas im Gange ist. Oder auch wenn es nicht so ist. Ich möchte nur keinen doppelten Aufwand.

Arch verwendet PKGBUILDs im Gegensatz zu pkgbuild von Apple.
Tassen statt CUPS sollten in Ordnung sein. Ich sehe keinen Kampf

Irgendwelche Neuigkeiten?

Was den Namen angeht

Wenn es vertraut sein soll, sollte es gists sein.

Wenn wir möchten, dass es markenfähig ist, macht sips cups . Ich würde jedoch dagegen argumentieren, ein solches generisches Feature zu brandmarken.

Gitlab verwendet Markenbegriffe

Im Fall von Gitlab haben sie „Merge Request“ anstelle von „Pull Request“ gewählt, was sinnvoll ist, wenn man den historischen Kontext betrachtet, was ein „Pull Request“ auf dem ursprünglichen Github im Vergleich zur „Auto-Merge“-Funktion war entwickelte sich später zu.

Ich wäre jedoch überrascht, wenn sie nicht auch ein wenig Google Keyword Planner recherchieren und feststellen würden, dass die Verwendung des Begriffs „Merge Request“ ihnen eine Art SEO-Vorteil verschafft.

Die neue Benutzererfahrung

Wie gesagt, ich persönlich sehe keinen großen Wert darin, ihm einen Markennamen zu geben.

Als neuer Benutzer wäre das die Art von Dingen, die mich mit den Augen verdrehen und denken lassen:

Warum muss jeder dasselbe Ding anders nennen, pfui

Abschließende Gedanken

gist ist KEINE Marke, es ist vertraut und macht Sinn

Wenn wir nicht gist verwenden, um vertraut zu sein, würde ich vorschlagen, dass wir mit dem Google Keyword Planner absichtlich einen Namen auswählen, um vertraute Begriffe zu finden, nach denen die Leute suchen, wenn sie bei "pastebin", "postbin", "Geist" usw.

Ich stimme der Zusammenführungsanfrage zu, macht für mich viel mehr Sinn.

Ich persönlich liebe die Idee, einen eigenen Namen zu verwenden, und ich denke ehrlich, für den Google-Index reicht es aus, ihn einfach so in der Dokumentation zu formulieren:

"Cups ist eine Lösung zum Speichern von Notizen und ähnelt der von GithubGist und Pastebin."

Warum Branding wichtig ist

Eigene Namen sind sinnvoll, da sie der Identifikation dienen - deshalb haben wir nicht alle den gleichen Namen.

Unternehmen investieren rund _die Hälfte ihres Einkommens_ in Branding, Pepsis Aussage "Wir brauchen keinen eigenen Namen, nennen wir ihn einfach Cola" ist absurd.

Lassen Sie uns auch über einzigartige Funktionen sprechen.

Nur meine Lebenserfahrung: Wenn Sie über GitHub sprechen, sollten Sie PR (Pull Requests) (oder Public Relations ?) verwenden, wenn Sie über GitLab sprechen, sollten Sie MR (Merge Requests) verwenden. Und wenn sich jemand zum Beispiel nicht mit GitLab auskennt, kann es so aussehen:

— Bitte öffnen Sie MR.
- HERR?
— Ja, wie … PR auf GitHub.

Und manchmal, besonders wenn Sie einen mehr als den anderen mögen, können Sie einen Fehler schreiben wie:

— Ich habe MR für Ihr GitHub-Projekt geöffnet.
- HERR?
— Oh, Entschuldigung, PR.

Dasselbe gilt für Snippets vs. Gists.

Sie können Gitea-Dinge benennen, wie Sie möchten, aber mit neuen Namen werden Sie die Terminologie aufblähen.

Warum nicht Idioten? Es ist leicht zu sagen, es bezieht sich auf Gitea, aber jetzt, wo ich schreibe ... plötzlich ... Gott sei verdammt ... Ich mag Kleinigkeiten lieber ... wenig wie Leckerbissen.
Hmm.. naja wenn da so ein Plugin kommt wäre das süß! wie auch immer es heißt. Danke übrigens, dass du gitea entwickelt hast. Schöne Software. Ich hätte auch gerne eine Funktion, wenn ich meine Server/Server-Konfigurationsdateien direkt in Gitea bearbeiten kann. Mit Versionshistorie und allem.

Mir persönlich ist es egal, wie du es nennst. Ich würde lieber zuerst den Fokus auf die Umsetzung sehen.

Heute wurde mir klar, dass ein einzelnes Skript nicht in einem Repo von Skripten sein sollte, die ich freigeben wollte, aber ich wollte dieses Skript auf die gleiche Weise abrufen, wie ich die anderen Skripte von anderen Computern abrufe. Es wäre dumm, ein ganzes Repo zu machen.

Das lässt mich glauben, dass private Gists eine gute Möglichkeit sind, geheime Dateien zu speichern, abzurufen und zu verfolgen.

Ich werde Namen nennen, während ich hier bin. Bisher gefällt mir ehrlich gesagt keine. Ich schlage vor, den Dienst Gistea und ein Snippet ein Blatt zu nennen. Gistea ist ein einzigartiges Schlüsselwort, obwohl es immer noch als das Wesentliche von Gitea erkennbar ist, und Blätter sind eine clevere und ansprechende Analogie.

Besonders "Tassen" mag ich nicht. Erinnert mich an eine bestimmte Marge-Simpson-Szene. "Cup... könntest du das buchstabieren?"

Ich schlage vor, den Dienst Gistea und ein Snippet ein Blatt zu nennen.

das gefällt mir :unschuldig:

Ich hätte gerne so etwas wie das Mockup in diesem Kommentar . Wenn ich etwas Neues lerne, habe ich immer das Gefühl, dass ich keinen guten Ort habe, um informelle Informationen und Notizen abzulegen, insbesondere für Dinge, die nicht in ein bestimmtes Projekt passen.

Als tatsächlichen Anwendungsfall habe ich in letzter Zeit daran gearbeitet, Drone (CI) zu lernen. Da es für jedes Projekt gilt, kann ich Ideen, Beispiele, Erinnerungen, Tipps usw. nirgendwo gut dokumentieren. Ich weiß nicht genug, um eine Dokumentationsseite für meine eigenen Richtlinien zu erstellen, und selbst wenn ich es täte, finde ich das kann eine Ablenkung sein. Ich könnte ein Projekt erstellen, nur um das Wiki zu verwenden, aber das Wiki erfordert eine Struktur, die zu formal ist, um einen Haufen zufälliger Gedanken und Ideen zu sammeln.

Im Moment habe ich mich für ein separates Projekt entschieden, bei dem ich den Issue-Tracker für informelle Notizen missbrauche, nur weil ich ihnen Labels hinzufügen kann. Im Allgemeinen versuche ich, die Dokumentation mithilfe von issue --> wiki --> formal docs weiterzuentwickeln, aber das funktioniert nicht gut für kleine Dinge wie Linux-CLI-Tipps usw. Ein Setup wie das im verlinkten Kommentar, wo ich Dinge kategorisieren und markieren könnte wäre fantastisch. Ich würde es eine Tonne verwenden.

https://github.com/fragmenta/fragmenta-cms
Hat Postgresql-Golang-Bits.
Mongodb golang Bits mysql, Sylla/Cassandra.
Aber ihre , zahlreiche pastebin Services,
( Konfigurationsdatei: gist, pastbin.. , wetpaste, etc )

https://secrethub.io/ , etwas besser für die Verteilung von API-Schlüsseln oder Geheimnissen an Boxen als für Gists.
Valt.io oder ähnliche geheime Tresordienste....

My.dev.box vs. gehackte.box.someplace.else
UID-Passwort, DNS ok ...
Wenn nicht am Heimatstandort oder zB Hosting-Server
töte es jetzt.
Kann Boxen vs. Gists für die Sicherheit genehmigen.

Ich will unbedingt privat sein, dass mein API-Flip-Key privat ist ...
Habe es zufällig auf einem Team-Entwickler-Blog geschmuggelt ...

OSINT INTELLIGENCE, kann meine vermeintlichen versteckten Dienste entlarven. Dh wesentliche ..

Python OSINT-Tools, Ihr Nummernschild, Ihre Adresse, Ihr Mobiltelefon, Ihr Mobilfunkanbieter usw.
Github/gitlab/etc für Schlüssel-API, eingebettete Passwörter ....

Filtern Sie also Blockzeichenfolgen, dh Passwörter, API-Schlüssel
Könnte sich auch als gesund erweisen.

Eine in go geschriebene Alternative: https://dev.sigpipe.me/dashie/git.txt