Pastebin service

[ShalokShalom]

• Gitea version (or commit ref): all
• Git version: all
• Operating system: all
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

I am used to Gist, the pastebin service, since it offers me the option to collect all my pasted code in one central place and that in the same interface, text editor and so on, which i use on Github, so all is very consistent.

I suggest to implement such a service for Gitea too, as Gitlab does it with their snippets.

This is something we all use, it provides users and developers the very same look and feel as in Gitea, is easy to implement (so far i as a newbie can see) and offer us a history of all the already posted code.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[laplix]

👍 for this one and I would suggest to name this feature cups,, as in cups of tea....

[pgaskin]

@laplix That might be a bit confusing with the Common Unix Printing Service. Also +1 as well.

[ShalokShalom]

cup? cupi? Or simply Pastebin?

[tboerger]

Or just snippets, I know it's not a fancy name ;)

[bkcsoft]

I still (see gogs issue) think this should be an external service. We could however make it injectable into Gitea 🙂

[ShalokShalom]

Optional features:

) Comment section
) Revisions (History)
) Syntax Highlighting, which is not even available in Gist
) Filter and sorting

A lot of +1 and many separately created issue reports about this proposal show a clear picture:

gogs/gogs#936

[bkcsoft]

on the other hand, it should be fairly simple to implement snippets.

Keep a hidden repo called _snippets (or similar), each snippet is a folder, a folder (or snippet) can contain multiple files. Done :)

[andreynering]

@bkcsoft On GitHub, each snippet is a Git repo (but can contain many files). But we can make it different.

I don't know if it should be part of Gitea or a separated project. If in Gitea, it would be easier to reuse code.

Anyway we should keep in mind that many people (me included) dislike the GitHub UI for Gists. I think we can do it better. There should be categories or tags to organize gists. It should be easy to find and search for existing Gists.

[bkcsoft]

Containing all snippets in one repo:

Pros:

• Easy to import/sync with your editor
• Fairly easy to implement (think copy-paste wiki-code)

Cons:

• Might get slow if you use snippets a lot
• Hard to remove a snippet completely (rewrite history, never nice)

---

Gist UI sucks indeed... much to be improved, just feels hacked together...

IMO we should contain everything regarding snippets to said repo (if a single one, otherwise I'm all down for submodules or whatever to keep track of them...), this includes categories (folders anyone? ) and tags

Having that as a file in the repo makes it easy to sync that to your editor as well, and makes it fairly simple to do searches 🙂

[ShalokShalom]

@andreynering I thought about tags as well, think this a good idea.
Maybe put these tags/categorys on the left side
So its easy to create and find specific pastebins:

[ShalokShalom]

May be a nice candidate to fork and adjust: https://github.com/defunkt/gist

[joubertredrat]

Or this, https://github.com/gmarik/Gistie

[bkcsoft]

defunkt/gist is a command line tool to speak to Gist, gmarik/Gistie is written in Ruby, both are not very relevant here 🙂

[lunny]

A pure golang library is preferred.

[joubertredrat]

@lunny @bkcsoft in my case, I post Gistie to be an option to see how this tool work and implement on Gitea, not to use a tool in Gitea.

[sinnlosername]

You could use it with a haste server, so people don't have to think about the space. Use hastebin.com by default and send the requests from the client using javascript, so the server won't be rate-limited. But also allow users to use their own haste-server. It could be implemented using an iframe.

[ShalokShalom]

I just found today an awesome tool that I want to share it with you: fssnip.net

[OmarAssadi]

Added onto the original bounty. Anyway, I figure having each snippet as its own repo is probably the nicest way to do it as far as history and offline modification goes.

The Bountysource link appears to be broken, by the way. Here is the current total:

[lunny]

Some ideas about Gist or we call it Cups ?

1. One cup is a specify repository, so that we can reuse all the old codes. Then we have mirrored, forked, cups and etc. repository types.
2. Every type repository could have different tabs(we store them on repo_unit). So every repository could load their units to tabs.
3. For cup repositories, there are only text files allowed(no folders, no images, no binary files) and the first file's name is also the repository's name. For example tea.go. The cup repository main UI will show the file's code and some comments. The comment could be on the bottom or on some code line.
   Also it has description or maybe classes.
4. For cup repositories, there is only one issue when created repository. All comments should follow this issue, then we can see all the comments on the cup UI.
5. cup repositories could be in /cups/<user_name>/<cup_name> and a separate entry on dashboard top menu. All other places will not show this type repository. But the repository name could not be reused on user's normal repository. This UI could be what @ShalokShalom's screenshots or any new idea. and provide code search since we have merged it on v1.3.

[ptman]

Take a look at gists, there can be several files.

[techknowlogick]

@lunny In regards to 3: with gists I sometimes use multiple files so I think limiting it to one might not work for some cases. Also, perhaps instead of enforcing a file extension we could either assume text/plain, or check if the file is a binary file and then just provide a link to the raw file.

Edit: ptman got to it first.

[tboerger]

Binary files for a pastebin service? Not a good idea.

Please don't require a file extension, otherwise you won't be able to share a makefile.

[lunny]

@ptman @tboerger @techknowlogick updated my comments.

[kolaente]

As some people didn't like how we integrated timetracking into the core, what about making pastebins an external service which integrates tightly with giteas api and uses it's repositories to store pastes?
I think even Githubs pastebin are kind of an external service...

[lunny]

@kolaente so the default is disabled. But as an external service, it will need more work than as an internal since repository, issue, comment are all ready.

[ShalokShalom]

Both? So Github Gists together with an own solution?
And Gitpin(s) for the internal name?

[lukewatts]

Owner EDIT: Please keep discussions safe for work...

[crueber]

I quite like the name Sips (in relation to (gi)Tea) for gists. :) Cups is good too, but brings to mind full sized repositories to me.

[lunny]

I have an unfinished PR name it cups

[crueber]

@Mikaela Hah! Hadn't even thought of that usage.

@lunny I went looking through PRs to see if there was something I could help with or riff off of and I didn't see anything matching pastebin, bin, paste, cup, or cups? I'd be happy to help move it forward if there's already something under way. Or even if there's not, for that matter. Just don't want to duplicate effort.

[ShalokShalom]

Arch is using PKGBUILDs, opposed to pkgbuild from Apple.
Cups instead of CUPS should be fine. I see no struggle

[BaxAndrei]

Any news?

[coolaj86]

As for the Name

If we want it to be familiar, it should be gists.

If we want it to be brandable, sips makes more sense than cups to me. However, I'd argue against branding such a generic feature.

Gitlab uses branded terms

In the case of Gitlab, they chose "merge request" instead of "pull request", which makes sense if you consider the historical context of what a "Pull Request" was on the original Github vs the "auto-merge" functionality that it later evolved into.

However, I would be surprised if they didn't also do a little Google Keyword Planner research and discover that using the term "Merge Request" gave them some sort of SEO advantage.

The New User Experience

As I said, I personally don't see see a lot of value in giving it a branded name.

As a new user, that would be the kind of thing that makes me roll my eyes and think:

why does everyone have to call the same thing different names, ugh

Final Thoughts

gist is NOT a trademark, it is familiar, and it makes sense

If we don't use gist to be familiar, I'd suggest we pick a name on purpose using Google Keyword Planner to discover familiar terms that people looking for when they arrive at "pastebin", "postbin", "gist", etc.

[ShalokShalom]

I agree with merge request, makes a lot more sense to me.

I personally love the idea to use an own name and I honestly think, for the google index it is enough to simply word it in the documentation as so:

"Cups is a solution to save notes and is similar to what GithubGist and Pastebin provides."

Why branding is important

Own names make sense since they help to indentify - thats why we all have not the same name.

Companies invest around half of their income into branding, Pepsi saying "we dont need an own name, just call it Cola" is absurd.

Also, let us talk about unique features.

[AlexWayfer]

Just my life experience: when you're talking about GitHub, you should use PR (Pull Requests) (or Public Relations?), when you're talking about GitLab — you should use MR (Merge Requests). And if somebody doesn't familiar with GitLab, for example, it can be like:

— Please, open MR.
— MR?
— Yeah, like… PR in GitHub.

And sometimes, especially if you like one more than another, you can write a mistake like:

— I've opened MR for your GitHub project.
— MR?
— Oh, sorry, PR.

The same about snippets vs gists.

You can call Gitea things as you want, but with new names you will bloat terminology.

[Jirido]

Why not gits? It is easy to say, it refers to gitea, but now when I writing.. suddenly... God be Damned.. I do like gitbits better.. little like tidbits.
Hmm.. well If there comes such a plugin it would be sweet! whatever it is called. Thank you for developing gitea by the way. Lovely software. I would also like a feature when i can edit my server/servers config files directly in Gitea. With version history and everything.

[tjrgg]

Personally, I don't care what you call it. I would rather see the focus on implementation first.

[dskrepps]

Today I realized a single script shouldn't be in a repo of scripts I was going to share, but I wanted to retrieve that script in the same way I retrieve the other scripts from other machines. It would be silly to make a whole repo.

That leads me to think private gists are a good way to store, retrieve, and track secrets files.

I'll chime in on names while I'm here. Frankly I don't like any so far. I suggest naming the service Gistea and a snippet a Leaf. Gistea is a unique keyword while still recognizable as Gitea's gists, and leaves are a clever and appealing analogy.

I especially don't like "cups". Reminds me of a certain Marge Simpson scene. "Cup... could you spell that?"

[ShalokShalom]

I suggest naming the service Gistea and a snippet a Leaf.

I like that 😇

[ryanjaeb]

I would love to have something like the mockup in this comment. Whenever I'm learning something new I always feel like I don't have a good place to put informal information and notes, especially for things that don't fit into a specific project.

As an actual use case, I've been working on learning Drone (CI) lately. Since it applies to any project, there's nowhere great for me to document ideas, example, reminders, tips, etc.. I don't know enough to start a documentation site for my own guidelines and, even if I did, I find that can be a distraction. I could make a project just to use the Wiki, but the Wiki requires a structure that's too formal for collecting a bunch of random thoughts and ideas.

Right now I've settled on a separate project where I misuse the issue tracker for informal notes just because I can add labels to them. In general I try to evolve documentation by using issue --> wiki --> formal docs, but that doesn't work well for small things like Linux CLI tips, etc.. A setup like the one in the linked comment where I could categorize and tag things would be fantastic. I would use it a ton.

[necrose99]

https://github.com/fragmenta/fragmenta-cms
Has postgresql golang bits.
Mongodb golang bits mysql, sylla/Cassandra.
However thiers , numerous pastebin Services,
( Config file: gist, pastbin.. , wetpaste, etc )

[necrose99]

https://secrethub.io/ , bit better for api keys or secrets to be distributed to boxes than gists.
Valt.io or similar secret vaulting services....

My.dev.box , vs hacked.box.someplace.else
Uid password, dns ok ...
If not in home location or ie hosting server
kill.. it now.
Can aprove boxes vs gists for Security.

I totaly wana private gist my api flipping key private...
Have some smuck on a team developer blog it by accident...

OSINT INTELLIGENCE, can unmask my supposed hidden services. Ie gists ..

Python OSINT tools , your license plate, your address, cellphone, carrier, etc.
Github/gitlab/etc for keys api , embeded passwords....

So filtering block strings ie passwords api keys
Might also prove SANE.

[ptman]

One alternative written in go: https://dev.sigpipe.me/dashie/git.txt

[gsantner]

this could be your chance to get into the project, learn something new and develop the proposed feature.
flaming mostly doesn't help at low priority issues/tasks 😉 .

[luwol03]

One simple solution to use such a feature already is to create a repository named gist and put all md files inside.

[joubertredrat]

@luwol03 I'm developing this feature here. Like wiki that is one git repo internally, Will have other repo called gist and for every new gist, will created new empty branch for this.

[21h]

this could be your chance to get into the project, learn something new and develop the proposed feature.
flaming mostly doesn't help at low priority issues/tasks .

was no reason to mark my comment as disruptive, I just bumped topic up and now we looking that someone writing code.

@luwol03 I'm developing this feature here. Like wiki that is one git repo internally, Will have other repo called gist and for every new gist, will created new empty branch for this.

it can be one ".gists" repo per user, also this repo name must be denied to create on repo create page.

original gists service on github looking like pr page with conversation, so gists repo in gitea can handle branch and pr for every committed text file. in this variation it can be easily integrated into current gitea.

[AlexWayfer]

was no reason to mark my comment as disruptive, I just bumped topic up and now we looking that someone writing code.

👍🏻 reaction under the first comment is enough, there is issues sorting by reactions. No need "to bump", there are 33 participants and a message like "there is no code" has about zero value. Sorry, please use appropriate tools, it's not old-school forum.

it can be one ".gists" repo per user, also this repo name must be denied to create on repo create page.

Oh, you're continuing to discuss naming instead of coding. 🙃 So sweet. Just… I don't know what to say anymore, please look at yourself and be patient, or try to make things better (like write a code).

[jolheiser]

I'm going to lock this thread in an effort to curb more bike-shedding.

Anyone who wishes to work on an implementation, please open an issue or PR describing your implementation and we can discuss it at that time.

[6543]

posibl. impl. #16670 proposal

[6543]

close this proposal since we wont have a anon pastebin in gitea - this is not it's mission ...