:+1: pour celui-ci et je suggérerais de nommer cette fonctionnalité tasses ,, comme dans les tasses de thé....

@laplix Cela pourrait être un peu déroutant avec le Common Unix Printing Service. +1 aussi.

Coupe? cupidon ? Ou simplement Pastebin ?

Ou juste des extraits, je sais que ce n'est pas un nom fantaisiste ;)

Je pense toujours (voir le problème de gogs) que cela devrait être un service externe. On pourrait cependant le rendre injectable dans Gitea 🙂

Caractéristiques optionnelles:

) Zone de commentaires
) Révisions (Historique)
) La coloration syntaxique, qui n'est même pas disponible dans Gist
) Filtrer et trier

Un grand nombre de +1 et de nombreux rapports de problème créés séparément à propos de cette proposition montrent une image claire :

gogits/gogs#936

d'autre part, il devrait être assez simple d'implémenter des extraits.

Conservez un référentiel caché appelé _snippets (ou similaire), chaque extrait est un dossier, un dossier (ou un extrait) peut contenir plusieurs fichiers. Terminé :)

@bkcsoft Sur GitHub, chaque extrait est un référentiel Git (mais peut contenir de nombreux fichiers). Mais nous pouvons le rendre différent.

Je ne sais pas si cela devrait faire partie de Gitea ou un projet séparé. Si à Gitea, il serait plus facile de réutiliser le code.

Quoi qu'il en soit, nous devons garder à l'esprit que beaucoup de gens (moi y compris) n'aiment pas l'interface utilisateur GitHub pour Gists. Je pense que nous pouvons faire mieux. Il devrait y avoir des catégories ou des balises pour organiser les points essentiels. Il devrait être facile de trouver et de rechercher des Gists existants.

Contenant tous les extraits dans un dépôt :

Avantages:

• Facile à importer/synchroniser avec votre éditeur
• Assez facile à mettre en œuvre :trollface: (pensez copier-coller le code wiki)

Les inconvénients:

• Peut devenir lent si vous utilisez beaucoup d'extraits
• Difficile de supprimer complètement un extrait (réécrire l'historique, jamais agréable)

Gist UI craint en effet... beaucoup à améliorer, on se sent juste piraté ensemble...

IMO, nous devrions contenir tout ce qui concerne les extraits dudit référentiel (s'il n'y en a qu'un seul, sinon je suis à fond pour les sous-modules ou quoi que ce soit pour en garder une trace...), cela inclut les catégories (dossiers n'importe qui ? :trollface :) et les balises

L'avoir en tant que fichier dans le référentiel facilite également la synchronisation avec votre éditeur et simplifie les recherches 🙂

@andreynering J'ai aussi pensé aux balises, je pense que c'est une bonne idée.
Peut-être mettre ces balises/catégories sur le côté gauche
Il est donc facile de créer et de trouver des pastebins spécifiques :

Peut être un bon candidat à bifurquer et à ajuster : https://github.com/defunkt/gist

Ou ceci, https://github.com/gmarik/Gistie

defunkt/gist est un outil en ligne de commande pour parler à Gist, gmarik/Gistie est écrit en Ruby, les deux ne sont pas très pertinents ici 🙂

Une bibliothèque golang pure est préférable.

@lunny @bkcsoft dans mon cas, je poste Gistie pour être une option pour voir comment cet outil fonctionne et s'implémente sur Gitea, pas pour utiliser un outil dans Gitea.

Vous pouvez l'utiliser avec un serveur rapide, afin que les gens n'aient pas à penser à l'espace. Utilisez hastebin.com par défaut et envoyez les requêtes du client en utilisant javascript, ainsi le serveur ne sera pas limité en débit. Mais permettez également aux utilisateurs d'utiliser leur propre serveur de hâte. Il pourrait être implémenté à l'aide d'un iframe.

Je viens de trouver aujourd'hui un outil génial que je veux partager avec vous : fssnip.net

Ajouté à la prime d'origine. Quoi qu'il en soit, je pense que chaque extrait de code est son propre dépôt est probablement la meilleure façon de le faire en ce qui concerne l'historique et la modification hors ligne.

Le lien Bountysource semble être rompu, soit dit en passant. Voici le total actuel :

Quelques idées sur Gist ou nous l'appelons Cups ?

1. Un cup est un référentiel spécifié, afin que nous puissions réutiliser tous les anciens codes. Ensuite, nous avons des types de référentiels en miroir, en bifurcation, en tasses, etc.
2. Chaque référentiel de type peut avoir des onglets différents (nous les stockons sur repo_unit). Ainsi, chaque référentiel pourrait charger ses unités dans des onglets.
3. Pour les référentiels cup , seuls les fichiers texte sont autorisés (pas de dossiers, pas d'images, pas de fichiers binaires) et le nom du premier fichier est également le nom du référentiel. Par exemple tea.go . L'interface utilisateur principale du référentiel cup affichera le code du fichier et quelques commentaires. Le commentaire peut être en bas ou sur une ligne de code.
   Il a également une description ou peut-être des classes.
4. Pour les référentiels cup , il n'y a qu'un seul problème lors de la création du référentiel. Tous les commentaires doivent suivre ce problème, puis nous pouvons voir tous les commentaires sur l'interface utilisateur cup .
5. Les référentiels cup peuvent se trouver dans /cups/<user_name>/<cup_name> et une entrée distincte dans le menu supérieur du tableau de bord. Tous les autres endroits n'afficheront pas ce référentiel de type. Mais le nom du référentiel n'a pas pu être réutilisé sur le référentiel normal de l'utilisateur. Cette interface utilisateur pourrait être les captures d'écran de @ShalokShalom ou toute nouvelle idée. et fournir une recherche de code puisque nous l'avons fusionné sur la v1.3.

Jetez un oeil à l'essentiel, il peut y avoir plusieurs fichiers.

@lunny En ce qui concerne 3: avec l'essentiel, j'utilise parfois plusieurs fichiers, donc je pense que le limiter à un pourrait ne pas fonctionner dans certains cas. De plus, peut-être qu'au lieu d'imposer une extension de fichier, nous pourrions soit supposer text/plain, soit vérifier si le fichier est un fichier binaire, puis fournir simplement un lien vers le fichier brut.

Edit: ptman y est arrivé en premier.

Fichiers binaires pour un service pastebin ? Pas une bonne idée.

Veuillez ne pas exiger d'extension de fichier, sinon vous ne pourrez pas partager un makefile.

@ptman @tboerger @techknowlogick a mis à jour mes commentaires.

Comme certaines personnes n'aimaient pas la façon dont nous avons intégré le suivi du temps dans le noyau, qu'en est-il de faire des pastebins un service externe qui s'intègre étroitement à l'api gitea et utilise ses référentiels pour stocker les pâtes ?
Je pense que même Githubs pastebin est une sorte de service externe...

@kolaente donc la valeur par défaut est désactivée. Mais en tant que service externe, il faudra plus de travail qu'en tant que service interne puisque le référentiel, le problème, le commentaire sont tous prêts.

Tous les deux? Donc Github Gists avec sa propre solution ?
Et Gitpin(s) pour le nom interne ?

Propriétaire EDIT : Veuillez garder les discussions en sécurité pour le travail...

+1

@lunny Que diriez-vous de cela. Réservez le référentiel _snippets.git et demandez-lui ensuite au service externe de l'utiliser pour les extraits de code ?

Edit : De cette façon, nous avons toujours accès aux commentaires (une fois que cela est implémenté et fusionné :trollface: )

Ou .snippets.git comme .wiki.git ? Et quel service externe est apte à le faire ?

Je pense que si nous avons un service externe qui gère le service pastebin, nous n'aurons pas besoin de réserver un référentiel pour cela.

Sinon, si nous implémentions le service pastebin dans gitea, j'aimerais l'idée d'un référentiel réservé, car un collage n'est généralement pas très important, je ne vois pas la nécessité de créer un référentiel à chaque fois, je pense que ce serait trop de référentiels après un certain temps lors de la création de certaines pâtes.

Je pense qu'un référentiel unique pourrait être utilisé et une nouvelle branche pour chaque pâte

Une raison pour laquelle nous ne devrions pas avoir de repo par pâte ? L'une des choses les plus intéressantes à propos des Gists de GitHub est qu'ils sont en fait des dépôts complets qui peuvent être clonés et validés.

je le vois aussi ainsi, 54

+1

Une fois possible : pouvons-nous simplement créer un bouton qui renvoie à un service pastebin personnalisé ?

Cela nous donne plusieurs avantages : Développement et personnalisation très rapides.
Pour être honnête:
Depuis que j'ai écrit ce problème, ma langue préférée a changé et son service pastebin prend même en charge les info-bulles et les bibliothèques.

Une implémentation Gitea est encore possible par la suite et c'est (si bien) zéro effort supplémentaire ?

Je ne suis pas en faveur d'un service de pastebin externe. La raison pour laquelle mon entreprise utilise Gitea est de l'avoir à l'intérieur d'un réseau interne pour la sécurité et l'accès interne. Nous ne pouvons pas utiliser de services externes, sinon nous utiliserions github ou bitbucket. L'effort devrait être mis sur la finalisation de la façon dont ils veulent l'implémenter dans gitea et ne pas se laisser distraire par des alternatives merdiques

Quoi qu'il en soit, dans la version principale, vous pouvez ajouter des onglets personnalisés aux liens externes dans vos modèles personnalisés

"externe" ne signifie pas nécessairement "dirigé par quelqu'un d'autre"
la modularité a aussi ses avantages...

@ShalokShalom Je suis d'accord qu'un lien serait une première étape possible, peut-être même juste pour ennuyer suffisamment quelqu'un pour améliorer quelque chose

@strk bien sûr, mais si nous voulons juste de la modularité et pas d'intégration, pourquoi avons-nous un suivi des problèmes ? sorties ? autre chose que ce que la gitose fournit

@lafriks Vraiment ? Comment?

@ptman Eh bien, pour intégrer à la fois - des liens vers d'autres pages et la propre solution - IS modulaire ?

@lukewatts L'idée de @strk vous convient-elle ?

@ShalokShalom Je m'attendrais à ce que le lien disparaisse une fois qu'une solution intégrée sera disponible

Le lien pour les actions génériques est utile de toute façon. Vous pouvez créer un lien vers la page de votre projet, etc.

Et la solution interne manquera de fonctionnalités, ce qui est important pour moi.

La coloration syntaxique est dans un état très précoce.

Qu'en est-il des info- bulles ?

@ShalokShalom oui, voir https://docs.gitea.io/en-us/customizing-gitea/ section "Ajouter des liens et des onglets" (cela a été ajouté dans #3308)

Merci beaucoup ^_^

@ShalokShalom Tant qu'un lien vers un service externe ne devient pas une excuse pour mettre la solution finale sur le long doigt, je suppose qu'un lien personnalisé serait bien..
Si je connaissais Go, j'aiderais plutôt que de râler. Je suis favorable à tout ce qui nous rapproche d'une bonne solution finalisée dans un délai raisonnable.

Vous pouvez également créer un lien vers un service interne, à condition que vous l'hébergiez vous-même ?

pour moi, quelque chose comme l'essentiel de GitHub ferait l'affaire, mais si certaines améliorations peuvent être apportées comme
balises/ catégories
ou encore un formatage style Medium/blog qui serait évidemment un plus

Je pense que l'intégration dans gitea sans trop de complications est la meilleure pour la philosophie de gitea

Un service Git auto-hébergé indolore .

Notant la possibilité de décentraliser en utilisant BitTorrent, IPFS ou privEOS. J'aime posséder des données, mais avoir quelque chose de plus fédéré pour cela serait un bon pic à voir.

Cette demande date donc maintenant de plus de 2 ans. Je me demande si des progrès ont été réalisés à ce sujet?

Personne ne travaille là-dessus.

Puisque nous avons maintenant un support oauth, nous pourrons peut-être créer quelque chose d'externe.

Oui, je pense que l'image de @ShalokShalom est belle https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny C'est Flarum.

J'aime l'idée de l' utilisateur supprimé .
Et les nommer tasses aussi, comme lunni l'a proposé. ^^

Tasses donc distribuées. :coeur coeur:
Partagez quelques tasses et faisons un goûter. :RÉ

Jeter dans certaines bibliothèques (en Go) à cette fin :

Noyau très simple : https://github.com/dyne/binnit
Assez (&) complet : https://github.com/andreimarcu/linx-server
Encore un autre : https://github.com/Parimer/spectre

Et un qui est déjà distribué :

Bloqué dans le développement, basé sur IPFS : https://github.com/beardog108/seedbin

Selon la suggestion de Ghost, j'ai trouvé une solution d'hébergement Git entièrement décentralisée (distribuée) et ils pourraient être intéressés par une coopération. Je pourrais leur demander aujourd'hui, si vous allez bien : https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

Y a-t-il une mise à jour à ce sujet ?
L'entretien supplémentaire rend les services externes interdits sur mon lieu de travail, mais un service de gitea cups nous serait utile.
Cette fonctionnalité serait un énorme plus pour moi :)

Je pense que cela devrait être dans la feuille de route de Gitea.

Oui, veuillez ajouter ceci !

J'aimerais bien voir ça aussi

Oui, veuillez ajouter ceci !

J'aimerais bien voir ça aussi

S'il vous plaît, utilisez les émotions pour un commentaire de départ :

Cela ne dérangera pas beaucoup de personnes abonnées par e-mail :

Et il a plus de fonctionnalités :

J'aime bien le nom Sips (par rapport à (gi)Tea) pour l'essentiel. :) Les tasses sont bien aussi, mais me rappellent les référentiels de taille normale.

J'ai un nom de relations publiques inachevé

Système d'impression Unix commun ? Désolé :rire:

@Mikaela Ha ! Je n'avais même pas pensé à cet usage.

@lunny J'ai parcouru les relations publiques pour voir s'il y avait quelque chose que je pouvais aider ou supprimer et je n'ai rien vu qui corresponde à pastebin, bin, paste, cup ou cups? Je serais heureux d'aider à le faire avancer s'il y a déjà quelque chose en cours. Ou même s'il n'y en a pas, d'ailleurs. Je ne veux pas dupliquer les efforts.

Arch utilise des PKGBUILD, contrairement à pkgbuild d'Apple.
Les tasses au lieu de CUPS devraient convenir. Je ne vois aucune lutte

Des nouvelles?

Quant au nom

Si nous voulons qu'il soit familier, il devrait être gists .

Si nous voulons qu'il soit personnalisable, sips a plus de sens que cups pour moi. Cependant, je m'opposerais à l'image de marque d'une fonctionnalité aussi générique.

Gitlab utilise des termes de marque

Dans le cas de Gitlab, ils ont choisi "merge request" au lieu de "pull request", ce qui est logique si vous considérez le contexte historique de ce qu'était une "Pull Request" sur le Github d'origine par rapport à la fonctionnalité "auto-merge" qu'il plus tard évolué en.

Cependant, je serais surpris s'ils ne faisaient pas également une petite recherche sur Google Keyword Planner et découvraient que l'utilisation du terme "Demande de fusion" leur donnait une sorte d'avantage SEO.

La nouvelle expérience utilisateur

Comme je l'ai dit, personnellement, je ne vois pas beaucoup de valeur à lui donner un nom de marque.

En tant que nouvel utilisateur, ce serait le genre de chose qui me ferait rouler les yeux et penser :

pourquoi tout le monde doit appeler la même chose des noms différents, pouah

Dernières pensées

gist n'est PAS une marque déposée, c'est familier et c'est logique

Si nous n'utilisons pas gist pour nous familiariser, je suggérerais de choisir un nom exprès à l'aide de Google Keyword Planner pour découvrir les termes familiers que les gens recherchent lorsqu'ils arrivent sur "pastebin", "postbin", "l'essentiel", etc.

Je suis d'accord avec la demande de fusion, c'est beaucoup plus logique pour moi.

Personnellement, j'aime l'idée d'utiliser un nom propre et je pense honnêtement que, pour l'index Google, il suffit de le formuler simplement dans la documentation comme suit :

"Cups est une solution pour enregistrer des notes et est similaire à ce que GithubGist et Pastebin fournissent."

Pourquoi l'image de marque est importante

Les noms propres ont un sens car ils aident à identifier - c'est pourquoi nous n'avons pas tous le même nom.

Les entreprises investissent environ _la moitié de leurs revenus_ dans l'image de marque, Pepsi disant "nous n'avons pas besoin d'un nom propre, appelez-le simplement Cola" est absurde.

Parlons également des caractéristiques uniques.

Juste mon expérience de vie : quand vous parlez de GitHub, vous devriez utiliser PR (Pull Requests) (ou Public Relations ?), quand vous parlez de GitLab — vous devriez utiliser MR (Merge Requests). Et si quelqu'un ne connaît pas GitLab, par exemple, cela peut ressembler à :

— S'il vous plaît, ouvrez MR.
- MONSIEUR?
- Ouais, comme… PR dans GitHub.

Et parfois, surtout si vous aimez l'un plus qu'un autre, vous pouvez écrire une erreur comme :

— J'ai ouvert MR pour votre projet GitHub.
- MONSIEUR?
— Oh, désolé, PR.

Il en va de même pour les extraits de code et les points essentiels.

Vous pouvez appeler Gitea comme vous voulez, mais avec de nouveaux noms, vous allez gonfler la terminologie.

Pourquoi pas les connards ? C'est facile à dire, ça fait référence à gitea, mais maintenant quand j'écris... tout à coup... Dieu soit damné... j'aime mieux les gitbits... un peu comme les friandises.
Hmm .. eh bien, s'il arrivait un tel plugin, ce serait sympa! quel que soit son nom. Merci d'avoir développé gitea au fait. Beau logiciel. J'aimerais également une fonctionnalité permettant d'éditer mes fichiers de configuration serveur/serveurs directement dans Gitea. Avec l'historique des versions et tout.

Personnellement, je me fiche de comment vous l'appelez. Je préférerais que l'accent soit mis sur la mise en œuvre en premier.

Aujourd'hui, j'ai réalisé qu'un seul script ne devrait pas être dans un référentiel de scripts que j'allais partager, mais je voulais récupérer ce script de la même manière que je récupère les autres scripts d'autres machines. Ce serait idiot de faire tout un repo.

Cela m'amène à penser que les informations essentielles privées sont un bon moyen de stocker, de récupérer et de suivre les fichiers secrets.

Je citerai des noms pendant que je suis ici. Franchement je n'en aime pas pour l'instant. Je suggère de nommer le service Gistea et un extrait une Feuille. Gistea est un mot-clé unique tout en restant reconnaissable comme l'essentiel de Gitea, et les feuilles sont une analogie intelligente et attrayante.

Je n'aime surtout pas les "tasses". Ça me rappelle une certaine scène de Marge Simpson. "Coupe... peux-tu épeler ça ?"

Je suggère de nommer le service Gistea et un extrait une Feuille.

j'aime bien :innocent:

J'aimerais avoir quelque chose comme la maquette dans ce commentaire . Chaque fois que j'apprends quelque chose de nouveau, j'ai toujours l'impression de ne pas avoir un bon endroit pour mettre des informations et des notes informelles, en particulier pour les choses qui ne correspondent pas à un projet spécifique.

En tant que cas d'utilisation réel, j'ai récemment travaillé sur l'apprentissage du drone (CI). Comme cela s'applique à n'importe quel projet, il n'y a nulle part où je puisse documenter des idées, des exemples, des rappels, des astuces, etc. peut être une distraction. Je pourrais faire un projet juste pour utiliser le Wiki, mais le Wiki nécessite une structure trop formelle pour collecter un tas de pensées et d'idées aléatoires.

À l'heure actuelle, je me suis installé sur un projet distinct où j'abuse du suivi des problèmes pour des notes informelles simplement parce que je peux leur ajouter des étiquettes. En général, j'essaie de faire évoluer la documentation en utilisant issue --> wiki --> formal docs , mais cela ne fonctionne pas bien pour les petites choses comme les astuces Linux CLI, etc. Une configuration comme celle du commentaire lié où je pourrais catégoriser et étiqueter les choses serait fantastique. Je l'utiliserais une tonne.

https://github.com/fragmenta/fragmenta-cms
A des bits golang postgresql.
Mongodb golang bits mysql, sylla/Cassandra.
Cependant thiers , de nombreux services pastebin,
(Fichier de configuration : gist, pastbin.. , wetpaste, etc.)

https://secrethub.io/ , un peu mieux pour les clés API ou les secrets à distribuer aux boîtes que les points essentiels.
Valt.io ou des services de stockage secrets similaires....

My.dev.box , vs hacked.box.someplace.else
Uid mot de passe, dns ok...
Si ce n'est pas dans l'emplacement d'origine ou sur le serveur d'hébergement
tuer .. maintenant.
Peut approuver les boîtes par rapport à l'essentiel pour la sécurité.

Je veux totalement l'essentiel privé de ma clé de retournement api privée ...
Avoir un peu de mal sur un blog de développeur d'équipe par accident ...

OSINT INTELLIGENCE, peut démasquer mes supposés services cachés. C'est-à-dire l'essentiel ..

Outils Python OSINT, votre plaque d'immatriculation, votre adresse, votre téléphone portable, votre opérateur, etc.
Github/gitlab/etc pour les clés api, les mots de passe intégrés....

Donc, filtrer les chaînes de blocs, c'est-à-dire les mots de passe, les clés API
Pourrait également prouver SANE.

Une alternative écrite en go : https://dev.sigpipe.me/dashie/git.txt