:+1: para este e eu sugiro nomear esse recurso como xícaras ,, como em xícaras de chá....

@laplix Isso pode ser um pouco confuso com o Common Unix Printing Service. Também +1 também.

xícara? cupi? Ou simplesmente Pastebin?

Ou apenas trechos, eu sei que não é um nome chique ;)

Eu ainda (veja a questão dos gogs) acho que isso deveria ser um serviço externo. No entanto, poderíamos torná-lo injetável no Gitea 🙂

Características opcionais:

) Seção de comentários
) Revisões (Histórico)
) Realce de sintaxe, que nem está disponível no Gist
) Filtrar e classificar

Muitos relatórios de problemas com +1 e muitos criados separadamente sobre esta proposta mostram uma imagem clara:

gogits/gogs#936

por outro lado, deve ser bastante simples implementar snippets.

Mantenha um repositório oculto chamado _snippets (ou similar), cada trecho é uma pasta, uma pasta (ou trecho) pode conter vários arquivos. Feito :)

@bkcsoft No GitHub, cada snippet é um repositório Git (mas pode conter muitos arquivos). Mas podemos fazer diferente.

Não sei se deveria fazer parte do Gitea ou um projeto separado. Se no Gitea, seria mais fácil reutilizar o código.

De qualquer forma, devemos ter em mente que muitas pessoas (inclusive eu) não gostam da IU do GitHub para Gists. Acho que podemos fazer melhor. Deve haver categorias ou tags para organizar gists. Deve ser fácil encontrar e pesquisar Gists existentes.

Contendo todos os snippets em um repositório :

Prós:

• Fácil de importar/sincronizar com seu editor
• Bastante fácil de implementar :trollface: (pense em copiar e colar o código wiki)

Contras:

• Pode ficar lento se você usar muito snippets
• Difícil remover um trecho completamente (reescrever o histórico, nunca é bom)

A interface do usuário do Gist é realmente uma droga ... muito a ser melhorado, apenas parece hackeado ...

IMO, devemos conter tudo sobre snippets para o referido repositório (se for um único, caso contrário, estou a fim de submódulos ou qualquer outra coisa para acompanhá-los ...), isso inclui categorias (pastas de alguém? :trollface:) e tags

Ter isso como um arquivo no repositório também facilita a sincronização com o seu editor e torna bastante simples fazer pesquisas 🙂

@andreynering Eu pensei em tags também, acho que é uma boa ideia.
Talvez coloque essas tags/categorias no lado esquerdo
Portanto, é fácil criar e encontrar pastebins específicos:

Pode ser um bom candidato para bifurcar e ajustar: https://github.com/defunkt/gist

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

defunkt/gist é uma ferramenta de linha de comando para falar com Gist, gmarik/Gistie é escrito em Ruby, ambos não são muito relevantes aqui 🙂

Uma biblioteca golang pura é preferida.

@lunny @bkcsoft no meu caso, posto Gistie para ser uma opção para ver como essa ferramenta funciona e implementa no Gitea, não para usar uma ferramenta no Gitea.

Você pode usá-lo com um servidor de pressa, para que as pessoas não precisem pensar no espaço. Use o hasbin.com por padrão e envie as solicitações do cliente usando javascript, para que o servidor não seja limitado por taxa. Mas também permite que os usuários usem seu próprio servidor de pressa. Pode ser implementado usando um iframe.

Acabei de encontrar hoje uma ferramenta incrível que quero compartilhar com você: fssnip.net

Adicionado à recompensa original. De qualquer forma, acho que ter cada trecho como seu próprio repositório é provavelmente a melhor maneira de fazer isso no que diz respeito ao histórico e à modificação offline.

A propósito, o link do Bountysource parece estar quebrado. Aqui está o total atual:

Algumas idéias sobre Gist ou nós chamamos de Cups ?

1. Um cup é um repositório específico, para que possamos reutilizar todos os códigos antigos. Em seguida, temos os tipos de repositório espelhado, bifurcado, copos e etc.
2. Cada repositório de tipo pode ter abas diferentes (nós as armazenamos em repo_unit). Assim, cada repositório pode carregar suas unidades em guias.
3. Para repositórios cup , existem apenas arquivos de texto permitidos (sem pastas, sem imagens, sem arquivos binários) e o nome do primeiro arquivo também é o nome do repositório. Por exemplo tea.go . A interface principal do repositório cup mostrará o código do arquivo e alguns comentários. O comentário pode estar na parte inferior ou em alguma linha de código.
   Também tem descrição ou talvez classes.
4. Para repositórios cup , há apenas um problema quando o repositório é criado. Todos os comentários devem seguir este problema, então podemos ver todos os comentários na cup UI.
5. Os repositórios cup podem estar em /cups/<user_name>/<cup_name> e uma entrada separada no menu superior do painel. Todos os outros lugares não mostrarão este tipo de repositório. Mas o nome do repositório não pôde ser reutilizado no repositório normal do usuário. Essa interface do usuário pode ser o que as capturas de tela de @ShalokShalom ou qualquer nova ideia. e fornecer pesquisa de código, já que a mesclamos na v1.3.

Dê uma olhada em gists, pode haver vários arquivos.

@lunny Em relação ao 3: com gists, às vezes uso vários arquivos, então acho que limitá-lo a um pode não funcionar para alguns casos. Além disso, talvez em vez de impor uma extensão de arquivo, poderíamos assumir texto/simples ou verificar se o arquivo é um arquivo binário e fornecer um link para o arquivo bruto.

Edit: ptman chegou primeiro.

Arquivos binários para um serviço pastebin? Não é uma boa ideia.

Por favor, não exija uma extensão de arquivo, caso contrário você não poderá compartilhar um makefile.

@ptman @tboerger @techknowlogick atualizou meus comentários.

Como algumas pessoas não gostaram de como integramos o timetracking ao núcleo, que tal tornar o pastebins um serviço externo que se integra perfeitamente com a giteas api e usa seus repositórios para armazenar pastas?
Acho que até o pastebin do Githubs é uma espécie de serviço externo ...

@kolaente para que o padrão seja desabilitado. Mas como um serviço externo, ele precisará de mais trabalho do que como um serviço interno, pois repositório, problema, comentário estão todos prontos.

Ambos? Então Github Gists junto com uma solução própria?
E Gitpin(s) para o nome interno?

Proprietário EDIT: Por favor, mantenha as discussões seguras para o trabalho...

+1

@lunny Que tal isso? Reserve o repositório _snippets.git e faça com que o serviço externo o use para snippets?

Edit: Dessa forma, ainda temos acesso aos comentários (uma vez implementados e mesclados :trollface: )

Ou .snippets.git como .wiki.git ? E qual serviço externo é adequado para isso?

Acho que se tivermos um serviço externo que lide com o serviço pastebin, não precisaremos reservar um repositório para isso.

Caso contrário, se implementássemos o serviço pastebin no gitea eu adoraria a ideia de um repositório reservado, como colar geralmente não é muito não vejo a necessidade de criar um repositório todas as vezes, acho que isso seria muitos repositórios após algum tempo ao criar algumas pastas.

Eu acho que um único repositório pode ser usado e um novo branch para cada pasta

Alguma razão pela qual não devemos ter um repositório por pasta? Uma das coisas mais legais sobre os Gists do GitHub é que eles são na verdade repositórios completos que podem ser clonados e comprometidos.

Eu também vejo assim, 54

+1

Uma vez possível: podemos simplesmente criar um botão que vincule a um serviço pastebin personalizado?

Isso nos dá várias vantagens: Desenvolvimento e personalização muito rápidos.
Para ser honesto:
Desde que escrevi esse problema, meu idioma preferido mudou e seu serviço pastebin suporta até dicas de ferramentas e bibliotecas.

Uma implementação do Gitea ainda é possível mais tarde e isso é (tão bom quanto) zero esforço adicional?

Não sou a favor de um serviço externo de pastebin. O motivo da minha empresa usar o Gitea é tê-lo dentro de uma rede interna por questões de segurança e acesso interno. Não podemos usar serviços externos, caso contrário estaríamos usando github ou bitbucket. O esforço deve ser colocado em finalizar como eles querem implementá-lo no gitea e não se distrair com alternativas de merda

De qualquer forma, na versão master, você pode adicionar guias personalizadas a links externos em seus modelos personalizados

"externo" não significa necessariamente "administrado por outra pessoa"
a modularidade também tem suas vantagens...

@ShalokShalom Eu concordo que um link seria um primeiro passo possível, talvez até mesmo para irritar alguém o suficiente para melhorar algo

@strk claro, mas se queremos apenas modularidade e sem integração, por que temos rastreamento de problemas? lançamentos? qualquer coisa além do que a gitose fornece

@lafriks Sério? Quão?

@ptman Bem, para integrar ambos - links para outras páginas e a própria solução - É modular?

@lukewatts A ideia de @strk é boa para você?

@ShalokShalom Espero que o link desapareça assim que uma solução integrada estiver disponível

O link para ações genéricas é útil de qualquer maneira. Você pode vincular a sua página de projeto e assim por diante.

E a solução interna não terá funcionalidade que é importante para mim.

O realce de sintaxe está em um estado muito inicial.

Como é isso do que sobre dicas de ferramentas ?

@ShalokShalom sim, veja https://docs.gitea.io/en-us/customizing-gitea/ seção "Adicionando links e guias" (isso foi adicionado em #3308)

Muito obrigado ^_^

@ShalokShalom Contanto que um link para um serviço externo não se torne uma desculpa para colocar a solução final no dedo longo, acho que um link personalizado seria bom.
Se eu conhecesse Go, ajudaria em vez de apenas reclamar. Sou a favor de qualquer coisa que nos aproxime de uma boa solução finalizada em tempo razoável.

Você também pode vincular a um serviço interno, desde que você mesmo o hospede?

para mim, qualquer coisa como o GitHub gists faria, mas se algumas melhorias puderem ser feitas, como
tags/categorias
ou mesmo formatação estilo Medium/blog que obviamente seria uma vantagem

Acho que a integração no gitea sem muita complicação é melhor para a filosofia do gitea

Um serviço Git auto-hospedado indolor .

Observando oportunidade de descentralizar usando BitTorrent, IPFS ou privEOS. Eu gosto de possuir por dados, mas ter algo mais federado para isso seria um pico legal de se ver.

Portanto, este pedido já tem mais de 2 anos. Gostaria de saber se houve algum progresso nisso?

Ninguém está trabalhando nisso.

Como agora temos suporte ao oauth, podemos construir alguma coisa externa.

Sim, acho a imagem de @ShalokShalom linda https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny Este é Flarum.

Eu amo a idéia do usuário excluído .
E nomeando-os de xícaras também, como Lunny propôs. ^^

Copos então distribuídos. :coração coração:
Distribua algumas xícaras e vamos fazer uma festa do chá. :D

Lançando algumas bibliotecas (em Go) para esse propósito:

Núcleo muito simples: https://github.com/dyne/binnit
Bastante (&) completo: https://github.com/andreimarcu/linx-server
Ainda outro: https://github.com/Parimer/spectre

E um que já está distribuído:

Parado em desenvolvimento, baseado em IPFS: https://github.com/beardog108/seedbin

De acordo com a sugestão do Ghost, encontrei uma solução de hospedagem Git totalmente descentralizada (distribuída) e eles podem estar interessados ​​em cooperar. Eu posso perguntar a eles hoje, se você estiver bem: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

Existe alguma atualização sobre isso?
A manutenção adicional torna os serviços externos inacessíveis no meu local de trabalho, mas um serviço de gitea cups seria útil para nós.
Esse recurso seria uma grande vantagem para mim :)

Acho que isso deveria estar no roteiro do Gitea.

Sim, por favor, adicione isso!

Adoraria ver isso também

Sim, por favor, adicione isso!

Adoraria ver isso também

Por favor, use as emoções para o comentário inicial:

Não incomodará muitas pessoas inscritas por e-mail:

E tem mais funcionalidades:

Eu gosto bastante do nome Sips (em relação ao (gi)Tea) para essências. :) Cups também é bom, mas me lembra repositórios de tamanho normal.

Eu tenho um nome de PR inacabado, copos

Sistema de impressão Unix comum? Desculpe :risos:

@Mikaela Hah! Nem tinha pensado nesse uso.

@lunny Eu fui olhar os PRs para ver se havia algo em que eu pudesse ajudar ou riffs e não vi nada que combinasse com pastebin, bin, paste, cup ou cups? Eu ficaria feliz em ajudar a avançar se já houver algo em andamento. Ou mesmo se não houver, para esse assunto. Só não quero duplicar o esforço.

Arch está usando PKGBUILDs, em oposição ao pkgbuild da Apple.
Copos em vez de COPOS deve ser bom. não vejo luta

Qualquer notícia?

Quanto ao nome

Se queremos que seja familiar, deve ser gists .

Se queremos que seja brandable, sips faz mais sentido do que cups para mim. No entanto, eu argumentaria contra a marca de um recurso tão genérico.

O Gitlab usa termos de marca

No caso do Gitlab, eles escolheram "merge request" em vez de "pull request", o que faz sentido se você considerar o contexto histórico do que era um "Pull Request" no Github original versus a funcionalidade "auto-merge" que ele posteriormente evoluiu para.

No entanto, eu ficaria surpreso se eles também não fizessem uma pequena pesquisa no Google Keyword Planner e descobrissem que usar o termo "Merge Request" deu a eles algum tipo de vantagem de SEO.

A nova experiência do usuário

Como eu disse, pessoalmente não vejo muito valor em dar-lhe um nome de marca.

Como um novo usuário, esse seria o tipo de coisa que me faria revirar os olhos e pensar:

por que todo mundo tem que chamar a mesma coisa de nomes diferentes, ugh

Pensamentos finais

gist NÃO é uma marca registrada, é familiar e faz sentido

Se não usarmos gist para nos familiarizarmos, sugiro que escolhamos um nome de propósito usando o Planejador de palavras-chave do Google para descobrir termos familiares que as pessoas procuram quando chegam a "pastebin", "postbin", "essência", etc.

Eu concordo com a solicitação de mesclagem, faz muito mais sentido para mim.

Pessoalmente, adoro a ideia de usar um nome próprio e, honestamente, acho que, para o índice do google, basta simplesmente colocá-lo na documentação da seguinte forma:

"Cups é uma solução para salvar notas e é semelhante ao que o GithubGist e o Pastebin fornecem."

Por que a marca é importante

Os nomes próprios fazem sentido, pois ajudam a identificar - é por isso que nem todos temos o mesmo nome.

As empresas investem cerca de _metade de sua renda_ em branding, Pepsi dizendo "não precisamos de um nome próprio, basta chamá-lo de Cola" é um absurdo.

Além disso, vamos falar sobre recursos exclusivos.

Apenas minha experiência de vida: quando você está falando sobre GitHub, você deve usar PR (Pull Requests) (ou Relações Públicas ?), quando você está falando sobre GitLab - você deve usar MR (Merge Requests). E se alguém não estiver familiarizado com o GitLab, por exemplo, pode ser assim:

— Por favor, abra o SR.
- SENHOR?
— Sim, tipo… PR no GitHub.

E às vezes, especialmente se você gosta mais de um do que de outro, pode escrever um erro como:

— Abri o MR para seu projeto do GitHub.
- SENHOR?
— Ah, desculpe, PR.

O mesmo sobre snippets vs gists.

Você pode chamar as coisas do Gitea como quiser, mas com novos nomes você vai inchar a terminologia.

Por que não dá? É fácil dizer, refere-se a gitea, mas agora quando eu escrevo... de repente... Deus seja condenado.. Eu gosto mais de gitbits.. pouco como petiscos.
Hmm.. bem, se vier um plugin desse tipo, seria legal! o que quer que seja chamado. Obrigado por desenvolver o gitea a propósito. Software adorável. Eu também gostaria de um recurso para editar meus arquivos de configuração do servidor/servidores diretamente no Gitea. Com histórico de versões e tudo.

Pessoalmente, eu não me importo como você chama isso. Eu preferiria ver o foco na implementação primeiro.

Hoje percebi que um único script não deveria estar em um repositório de scripts que eu ia compartilhar, mas queria recuperar esse script da mesma forma que recupero os outros scripts de outras máquinas. Seria tolice fazer um repositório inteiro.

Isso me leva a pensar que gists particulares são uma boa maneira de armazenar, recuperar e rastrear arquivos secretos.

Vou falar sobre nomes enquanto estiver aqui. Sinceramente não gosto de nenhum até agora. Sugiro nomear o serviço Gistea e um trecho de Leaf. Gistea é uma palavra-chave única, embora ainda reconhecível como a essência de Gitea, e as folhas são uma analogia inteligente e atraente.

Eu particularmente não gosto de "copos". Me lembra uma certa cena de Marge Simpson. "Copa... você poderia soletrar isso?"

Sugiro nomear o serviço Gistea e um trecho de Leaf.

Eu gosto disso :inocente:

Eu adoraria ter algo como a maquete neste comentário . Sempre que estou aprendendo algo novo, sempre sinto que não tenho um bom lugar para colocar informações informais e anotações, principalmente para coisas que não se encaixam em um projeto específico.

Como um caso de uso real, tenho trabalhado no aprendizado de Drone (CI) ultimamente. Como se aplica a qualquer projeto, não há nenhum lugar bom para documentar idéias, exemplos, lembretes, dicas, etc. Não sei o suficiente para iniciar um site de documentação para minhas próprias diretrizes e, mesmo que o fizesse, acho pode ser uma distração. Eu poderia fazer um projeto apenas para usar o Wiki, mas o Wiki requer uma estrutura formal demais para coletar um monte de pensamentos e ideias aleatórios.

No momento, resolvi um projeto separado em que uso mal o rastreador de problemas para anotações informais apenas porque posso adicionar rótulos a elas. Em geral, tento evoluir a documentação usando issue --> wiki --> formal docs , mas isso não funciona bem para pequenas coisas como dicas de CLI do Linux, etc. Uma configuração como a do comentário vinculado onde eu poderia categorizar e marcar as coisas seria fantástico. Eu usaria uma tonelada.

https://github.com/fragmenta/fragmenta-cms
Tem bits golang postgresql.
Mongodb golang bits mysql, sylla/Cassandra.
No entanto, seus numerosos serviços pastebin,
( arquivo de configuração: gist, pastbin .. , pasta úmida, etc )

https://secrethub.io/ , um pouco melhor para chaves ou segredos de API serem distribuídos para caixas do que gists.
Valt.io ou serviços secretos semelhantes....

My.dev.box , vs hacked.box.someplace.else
Senha uid, dns ok...
Se não estiver no local de origem ou no servidor de hospedagem
mate.. agora.
Pode aprovar caixas vs essências para segurança.

Eu totalmente quero um gist privado da minha api lançando a chave privada ...
Tenha algum smuck em um blog de desenvolvedor de equipe por acidente ...

OSINT INTELLIGENCE, pode desmascarar meus supostos serviços ocultos. Ou seja, essências..

Ferramentas Python OSINT, sua placa, seu endereço, celular, operadora, etc.
Github/gitlab/etc para keys api , senhas incorporadas....

Então, filtrando strings de bloco, ou seja, senhas, chaves de API
Também pode provar SANE.

Uma alternativa escrita em go: https://dev.sigpipe.me/dashie/git.txt