:+1: para este y sugeriría nombrar esta característica tazas , como en tazas de té....

@laplix Eso podría ser un poco confuso con el Servicio de impresión común de Unix. También +1 también.

¿taza? cupí? ¿O simplemente Pastebin?

O solo fragmentos, sé que no es un nombre elegante;)

Todavía (ver problema de gogs) creo que esto debería ser un servicio externo. Sin embargo, podríamos hacerlo inyectable en Gitea 🙂

Características opcionales:

) Sección de comentarios
) Revisiones (Historial)
) Resaltado de sintaxis, que ni siquiera está disponible en Gist
) Filtrar y ordenar

Una gran cantidad de +1 y muchos informes de problemas creados por separado sobre esta propuesta muestran una imagen clara:

gogits/gogs#936

por otro lado, debería ser bastante simple implementar fragmentos.

Mantenga un repositorio oculto llamado _snippets (o similar), cada fragmento es una carpeta, una carpeta (o fragmento) puede contener varios archivos. Hecho :)

@bkcsoft En GitHub, cada fragmento es un repositorio de Git (pero puede contener muchos archivos). Pero podemos hacerlo diferente.

No sé si debería ser parte de Gitea o un proyecto separado. Si estuviera en Gitea, sería más fácil reutilizar el código.

De todos modos, debemos tener en cuenta que a muchas personas (incluido yo) no les gusta la interfaz de usuario de GitHub para Gists. Creo que podemos hacerlo mejor. Debe haber categorías o etiquetas para organizar lo esencial. Debería ser fácil encontrar y buscar Gists existentes.

Contiene todos los fragmentos en un repositorio :

Ventajas:

• Fácil de importar/sincronizar con su editor
• Bastante fácil de implementar :trollface: (piense en copiar y pegar código wiki)

Contras:

• Podría volverse lento si usa mucho fragmentos
• Es difícil eliminar un fragmento por completo (reescribir el historial, nunca agradable)

Gist UI realmente apesta... mucho por mejorar, simplemente se siente pirateado...

En mi opinión, deberíamos contener todo lo relacionado con fragmentos de dicho repositorio (si es uno solo, de lo contrario, estoy dispuesto a submódulos o lo que sea para realizar un seguimiento de ellos ...), esto incluye categorías (¿carpetas, alguien? :trollface:) y etiquetas

Tener eso como un archivo en el repositorio también facilita la sincronización con su editor, y hace que sea bastante simple realizar búsquedas 🙂

@andreynering También pensé en las etiquetas, creo que es una buena idea.
Tal vez ponga estas etiquetas/categorías en el lado izquierdo
Así que es fácil de crear y encontrar pastebins específicos:

Puede ser un buen candidato para bifurcar y ajustar: https://github.com/defunkt/gist

O esto, https://github.com/gmarik/Gistie

defunkt/gist es una herramienta de línea de comandos para hablar con Gist, gmarik/Gistie está escrito en Ruby, ambos no son muy relevantes aquí 🙂

Se prefiere una biblioteca pura de golang.

@lunny @bkcsoft en mi caso, publico a Gistie como una opción para ver cómo funciona esta herramienta e implementarla en Gitea, no para usar una herramienta en Gitea.

Podría usarlo con un servidor urgente, para que la gente no tenga que pensar en el espacio. Utilice hastebin.com de forma predeterminada y envíe las solicitudes del cliente mediante javascript, por lo que el servidor no tendrá limitaciones de velocidad. Pero también permita a los usuarios usar su propio servidor rápido. Se podría implementar usando un iframe.

Acabo de encontrar hoy una herramienta increíble que quiero compartir con ustedes: fssnip.net

Agregado a la recompensa original. De todos modos, creo que tener cada fragmento como su propio repositorio es probablemente la mejor manera de hacerlo en lo que respecta al historial y la modificación fuera de línea.

Por cierto, el enlace de Bountysource parece estar roto. Aquí está el total actual:

¿Algunas ideas sobre Gist o lo llamamos Cups ?

1. Un cup es un repositorio específico, para que podamos reutilizar todos los códigos antiguos. Luego tenemos tipos de repositorio reflejados, bifurcados, tazas, etc.
2. Cada tipo de repositorio podría tener diferentes pestañas (las almacenamos en repo_unit). Entonces cada repositorio podría cargar sus unidades en pestañas.
3. Para los repositorios cup , solo se permiten archivos de texto (sin carpetas, sin imágenes, sin archivos binarios) y el nombre del primer archivo es también el nombre del repositorio. Por ejemplo tea.go . La interfaz de usuario principal del repositorio cup mostrará el código del archivo y algunos comentarios. El comentario podría estar en la parte inferior o en alguna línea de código.
   También tiene descripción o quizás clases.
4. Para los repositorios cup , solo hay un problema cuando se crea el repositorio. Todos los comentarios deben seguir este problema, luego podemos ver todos los comentarios en la interfaz de usuario cup .
5. Los repositorios cup podrían estar en /cups/<user_name>/<cup_name> y una entrada separada en el menú superior del tablero. Todos los demás lugares no mostrarán este tipo de repositorio. Pero el nombre del repositorio no se pudo reutilizar en el repositorio normal del usuario. Esta interfaz de usuario podría ser las capturas de pantalla de @ShalokShalom o cualquier idea nueva. y proporcionar búsqueda de código ya que lo hemos fusionado en v1.3.

Eche un vistazo a las esencias, puede haber varios archivos.

@lunny Con respecto a 3: con gists, a veces uso varios archivos, así que creo que limitarlo a uno podría no funcionar en algunos casos. Además, tal vez en lugar de aplicar una extensión de archivo, podríamos asumir texto/sin formato, o verificar si el archivo es un archivo binario y luego simplemente proporcionar un enlace al archivo sin formato.

Editar: ptman llegó primero.

¿Archivos binarios para un servicio pastebin? No es Buena idea.

No requiera una extensión de archivo, de lo contrario no podrá compartir un archivo MAKE.

@ptman @tboerger @techknowlogick actualizó mis comentarios.

Como a algunas personas no les gustó la forma en que integramos el seguimiento de tiempo en el núcleo, ¿qué hay de hacer que pastebins sea un servicio externo que se integre estrechamente con giteas api y use sus repositorios para almacenar pastas?
Creo que incluso el pastebin de Github es una especie de servicio externo...

@kolaente por lo que el valor predeterminado está deshabilitado. Pero como servicio externo, necesitará más trabajo que como interno, ya que el repositorio, el problema y el comentario están listos.

¿Ambas cosas? Entonces, ¿Github Gists junto con una solución propia?
¿Y Gitpin(s) para el nombre interno?

PROPIETARIO EDITAR: Mantenga las discusiones seguras para el trabajo...

+1

@lunny ¿Qué tal esto? ¿Reservar el repositorio _snippets.git y luego hacer que el servicio externo lo use para fragmentos?

Editar: de esa manera todavía tenemos acceso a los comentarios (una vez que se implemente y se fusione :trollface: )

¿O .snippets.git como .wiki.git ? ¿Y qué servicio externo es adecuado para hacer eso?

Creo que si tenemos un servicio externo que maneja el servicio pastebin, no necesitaremos reservar un repositorio para esto.

De lo contrario, si implementáramos el servicio pastebin en gitea, me encantaría la idea de un repositorio reservado, ya que pegar no suele ser mucho. No veo la necesidad de crear un repositorio cada vez, creo que esto sería demasiados repositorios después de algún tiempo al crear algunas pastas.

Creo que se podría usar un repositorio único y una nueva rama para cada pegado.

¿Alguna razón por la que no deberíamos tener un repositorio por pegado? Una de las mejores cosas de Gists de GitHub es que en realidad son repositorios completos que se pueden clonar y confirmar.

Yo también lo veo así, 54

+1

Una vez posible: ¿Podemos simplemente crear un botón que se vincule a un servicio de pastebin personalizado?

Esto nos da varias ventajas: Muy rápido desarrollo y personalización.
Para ser sincero:
Desde que escribí este problema, mi idioma preferido cambió y su servicio pastebin admite incluso información sobre herramientas y bibliotecas.

¿Todavía es posible una implementación de Gitea más adelante y esto es (tan bueno como) cero esfuerzo adicional?

No estoy a favor de un servicio de pastebin externo. La razón por la que mi empresa usa Gitea es para tenerlo dentro de una red interna por seguridad y acceso interno. No podemos usar servicios externos, de lo contrario estaríamos usando github o bitbucket. El esfuerzo debe ponerse en finalizar cómo quieren implementarlo en gitea y no distraerse con alternativas de mierda.

De todos modos, en la versión maestra, puede agregar pestañas personalizadas a enlaces externos en sus plantillas personalizadas

"externo" no significa necesariamente "dirigido por otra persona"
la modularidad también tiene sus ventajas...

@ShalokShalom Estoy de acuerdo en que un enlace sería un posible primer paso, tal vez incluso solo para molestar a alguien lo suficiente como para hacer algo mejor.

@strk seguro, pero si solo queremos modularidad y no integración, ¿por qué tenemos seguimiento de problemas? lanzamientos? cualquier cosa que no sea lo que proporciona la gitosis

@lafriks ¿En serio? ¿Cómo?

@ptman Bueno, para integrar ambos, enlaces a otras páginas y la propia solución, ¿ ES modular?

@lukewatts ¿Te parece bien la idea de @strk ?

@ShalokShalom Espero que el enlace desaparezca una vez que esté disponible una solución integrada

El enlace para acciones genéricas es útil de todos modos. Puede vincular a la página de su proyecto y así sucesivamente.

Y la solución interna carecerá de funcionalidad que es importante para mí.

El resaltado de sintaxis se encuentra en un estado muy temprano.

¿Cómo es eso que sobre Tooltips ?

@ShalokShalom sí, consulte la sección https://docs.gitea.io/en-us/customizing-gitea/ "Agregar enlaces y pestañas" (esto se agregó en el n.° 3308)

Muchas gracias ^_^

@ShalokShalom Siempre que un enlace a un servicio externo no se convierta en una excusa para poner la solución final en el dedo largo, supongo que un enlace personalizado estaría bien.
Si conociera a Go, ayudaría en lugar de quejarme. Estoy a favor de cualquier cosa que nos acerque a una buena solución finalizada en un tiempo razonable.

También puede vincular a un servicio interno, siempre que lo aloje usted mismo.

para mí, cualquier cosa como GitHub gists funcionaría, pero si se pueden hacer algunas mejoras como
etiquetas/categorías
o incluso formato de estilo medio/blog que obviamente sería una ventaja

Creo que la integración en gitea sin mucha complicación es lo mejor para la filosofía de giteas.

Un servicio Git autohospedado sin complicaciones.

Observando la oportunidad de descentralizar usando BitTorrent, IPFS o privEOS. Me gusta poseer por datos, pero tener algo más federado para esto sería un buen aumento para ver.

Así que esta solicitud tiene ahora más de 2 años. Me pregunto si se ha hecho algún progreso en esto en absoluto.

Nadie está trabajando en esto.

Dado que ahora tenemos soporte de autenticación, es posible que podamos construir algo externo.

Sí, creo que la imagen de @ShalokShalom es hermosa https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny Este es Flarum.

Me encanta la idea del usuario eliminado .
Y nombrándoles copas también, como propuso lunny. ^^

Tazas tan distribuidas. :Corazón corazón:
Comparta algunas tazas y hagamos una fiesta de té. :D

Lanzar algunas bibliotecas (en Go) para ese propósito:

Núcleo muy simple: https://github.com/dyne/binnit
Bonito (&) completo: https://github.com/andreimarcu/linx-server
Otro más: https://github.com/Parimer/spectre

Y uno que ya está repartido:

Estancado en desarrollo, basado en IPFS: https://github.com/beardog108/seedbin

Según la sugerencia de Ghost, encontré una solución de alojamiento Git completamente descentralizada (distribuida) y es posible que estén interesados ​​en cooperar. Podría preguntarles hoy, si está bien: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

¿Hay alguna actualización sobre esto?
El mantenimiento adicional hace que los servicios externos no funcionen en mi lugar de trabajo, pero un servicio de tazas de gitea sería útil para nosotros.
Esta característica sería una gran ventaja para mí :)

Creo que esto debería estar en la hoja de ruta de Gitea.

¡Sí, por favor agregue esto!

Me encantaría ver esto también

¡Sí, por favor agregue esto!

Me encantaría ver esto también

Por favor, use las emociones para el comentario de inicio de problema:

No molestará a muchas personas suscritas por correo electrónico:

Y tiene más funcionalidades:

Me gusta bastante el nombre Sips (en relación con (gi)Tea) para lo esencial. :) Cups también es bueno, pero me recuerda a los repositorios de tamaño completo.

Tengo un nombre de relaciones públicas sin terminar.

¿Sistema de impresión Unix común? lo siento :risa:

@Mikaela Jaja ! Ni siquiera había pensado en ese uso.

@lunny Revisé las relaciones públicas para ver si había algo en lo que pudiera ayudar o en lo que pudiera hacer un riff y no vi nada que coincidiera con pastebin, bin, paste, cup o cups. Me encantaría ayudar a que avance si ya hay algo en marcha. O incluso si no lo hay, para el caso. Simplemente no quiero duplicar el esfuerzo.

Arch está usando PKGBUILDs, a diferencia de pkgbuild de Apple.
Las tazas en lugar de CUPS deberían estar bien. no veo lucha

¿Hay noticias?

En cuanto al nombre

Si queremos que sea familiar, debería ser gists .

Si queremos que sea de marca, sips tiene más sentido que cups para mí. Sin embargo, argumentaría en contra de calificar una característica tan genérica.

Gitlab usa términos de marca

En el caso de Gitlab, eligieron "solicitud de fusión" en lugar de "solicitud de extracción", lo que tiene sentido si se considera el contexto histórico de lo que era una "Solicitud de extracción" en el Github original frente a la funcionalidad de "combinación automática" que más tarde se convirtió en.

Sin embargo, me sorprendería si no hicieran también una pequeña investigación en el Planificador de palabras clave de Google y descubrieran que usar el término "Solicitud de combinación" les dio algún tipo de ventaja de SEO.

La nueva experiencia de usuario

Como dije, personalmente no veo mucho valor en darle un nombre de marca.

Como nuevo usuario, ese sería el tipo de cosa que me hace poner los ojos en blanco y pensar:

¿Por qué todos tienen que llamar a lo mismo con diferentes nombres, ugh?

Pensamientos finales

gist NO es una marca comercial, es familiar y tiene sentido

Si no usamos gist para familiarizarnos, sugiero que elijamos un nombre a propósito usando Google Keyword Planner para descubrir términos familiares que las personas buscan cuando llegan a "pastebin", "postbin", "esencia", etc

Estoy de acuerdo con la solicitud de fusión, tiene mucho más sentido para mí.

Personalmente, me encanta la idea de usar un nombre propio y, sinceramente, creo que para el índice de Google es suficiente simplemente escribirlo en la documentación de la siguiente manera:

"Cups es una solución para guardar notas y es similar a lo que ofrecen GithubGist y Pastebin".

Por qué es importante la marca

Los nombres propios tienen sentido ya que ayudan a identificarse, por eso no todos tenemos el mismo nombre.

Las empresas invierten alrededor de la mitad de sus ingresos en la creación de marcas, Pepsi diciendo "no necesitamos un nombre propio, simplemente llámalo Cola" es absurdo.

Además, hablemos de características únicas.

Solo mi experiencia de vida: cuando habla de GitHub, debe usar PR (Solicitudes de extracción) (¿o relaciones públicas ?), Cuando habla de GitLab, debe usar MR (Solicitudes de combinación). Y si alguien no está familiarizado con GitLab, por ejemplo, puede ser como:

— Por favor, abra MR.
- ¿SRES?
— Sí, como... relaciones públicas en GitHub.

Y a veces, sobre todo si te gusta más uno que otro, puedes escribir algún error como:

— Abrí MR para su proyecto de GitHub.
- ¿SRES?
— Oh, lo siento, PR.

Lo mismo sobre fragmentos vs esencias.

Puedes llamar a Gitea las cosas como quieras, pero con nombres nuevos inflarás la terminología.

¿Por qué no gits? Es fácil de decir, se refiere a gitea, pero ahora cuando escribo... de repente... Maldita sea... Me gustan más los gitbits... pequeños como cositas.
Hmm ... bueno, si llega un complemento de este tipo, ¡sería genial! como se llame. Gracias por desarrollar gitea por cierto. Precioso software. También me gustaría una función cuando pueda editar mis archivos de configuración de servidor/servidores directamente en Gitea. Con historial de versiones y todo.

Personalmente, no me importa cómo lo llames. Preferiría ver el enfoque en la implementación primero.

Hoy me di cuenta de que un solo script no debería estar en un repositorio de scripts que iba a compartir, pero quería recuperar ese script de la misma manera que recupero los otros scripts de otras máquinas. Sería una tontería hacer un repositorio completo.

Eso me lleva a pensar que las esencias privadas son una buena manera de almacenar, recuperar y rastrear archivos secretos.

Hablaré de nombres mientras esté aquí. Francamente no me gusta ninguno hasta ahora. Sugiero nombrar el servicio Gistea y un fragmento como Leaf. Gistea es una palabra clave única aunque todavía reconocible como la esencia de Gitea, y las hojas son una analogía inteligente y atractiva.

Especialmente no me gustan las "tazas". Me recuerda a cierta escena de Marge Simpson. "Copa... ¿podrías deletrearlo?"

Sugiero nombrar el servicio Gistea y un fragmento como Leaf.

eso me gusta :inocente:

Me encantaría tener algo como la maqueta en este comentario . Cada vez que estoy aprendiendo algo nuevo, siempre siento que no tengo un buen lugar para poner información y notas informales, especialmente para cosas que no encajan en un proyecto específico.

Como caso de uso real, últimamente he estado trabajando en aprender Drone (CI). Dado que se aplica a cualquier proyecto, no hay ningún lugar ideal para mí para documentar ideas, ejemplos, recordatorios, sugerencias, etc. No sé lo suficiente como para iniciar un sitio de documentación para mis propias pautas y, aunque lo supiera, encuentro puede ser una distracción. Podría hacer un proyecto solo para usar Wiki, pero Wiki requiere una estructura que es demasiado formal para recopilar un montón de pensamientos e ideas al azar.

En este momento, me he decidido por un proyecto separado en el que uso mal el rastreador de problemas para notas informales solo porque puedo agregarles etiquetas. En general, trato de hacer evolucionar la documentación usando issue --> wiki --> formal docs , pero eso no funciona bien para cosas pequeñas como sugerencias de CLI de Linux, etc. Una configuración como la del comentario vinculado donde podría categorizar y etiquetar cosas sería fantástico Lo usaría una tonelada.

https://github.com/fragmenta/fragmenta-cms
Tiene bits golang postgresql.
Mongodb golang bits mysql, sylla/Cassandra.
Sin embargo, hay numerosos servicios de pastebin,
(Archivo de configuración: esencia, pastbin..., pasta húmeda, etc.)

https://secrethub.io/ , es un poco mejor que las claves de API o los secretos se distribuyan a las cajas que a las esencias.
Valt.io o servicios de bóveda secreta similares....

My.dev.box , vs hacked.box.someplace.else
Uid contraseña, dns ok...
Si no está en la ubicación de su casa o, por ejemplo, en un servidor de alojamiento
matar.. ahora.
Puede aprobar cajas vs esencias para seguridad.

I totalmente quiero privado esencia mi api volteando clave privada...
Tener algo de fanfarronada en el blog de un desarrollador del equipo por accidente...

INTELIGENCIA OSINT, puede desenmascarar mis supuestos servicios ocultos. Es decir, esencias..

Herramientas Python OSINT, tu matrícula, tu dirección, móvil, operador, etc.
Github/gitlab/etc para claves api, contraseñas incrustadas....

Por lo tanto, filtrar cadenas de bloque, es decir, contraseñas, claves API
También podría resultar SANO.

Una alternativa escrita en go: https://dev.sigpipe.me/dashie/git.txt