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

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

cup? cupi? Or simply Pastebin?

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

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

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:

gogits/gogs#936

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 :)

@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.

Containing all snippets in one repo:

Pros:

• Easy to import/sync with your editor
• Fairly easy to implement :trollface: (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? :trollface:) 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 🙂

@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:

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

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

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

A pure golang library is preferred.

@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.

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.

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

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:

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.

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

@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.

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.

@ptman @tboerger @techknowlogick updated my comments.

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...

@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.

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

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

+1

@lunny How about this. Reserve the repository _snippets.git and then have the external service use that for snippets?

Edit: That way we still have access to comments (once that is implemented and merged :trollface: )

Or .snippets.git just like .wiki.git? And which external service is suitable to do that?

I think if we have an external service which handles the pastebin service we won't need to reserve a repository for this.

Otherwise, if we'd implement the pastebin service in gitea I'd love the idea of a reserved repsository, as a paste is usually not very much I don't see the need to create a repository every time, I think this would be too much repositories afte some time when creating some pastes.

I think single repository could be used and new branch for each paste

Any reason why we shouldn't have a repo per paste? One of coolest things about GitHub's Gists is that they are actually full repos that can be cloned and committed to.

I see it also so, 54

+1

Once possible: Can we simply create a button that links to a custom pastebin service?

This gives us several advantages: Very quick development and customisation.
To be honest:
Since I wrote this issue did my prefered language change and its pastebin service supports even tooltips and libraries.

A Gitea implementation is still possible later and this is (so good as) zero additional effort?

I'm not in favour of an external pastebin service. The reason my company uses Gitea is to have it inside an internal network because for security and internal access. We can't use external services otherwise we'd be using github or bitbucket. The effort should be put into finalizing how they want implement it in gitea and not getting distracted with crap alternatives

Anyway in master version you can add custom tabs to external links in your custom templates

"external" doesn't necessarely mean "run by someone else"
modularity has its advantages too...

@ShalokShalom I agree that a link would be a possible first step, maybe even just to annoy someone enough to make something better

@strk sure, but if we just want modularity, and no integration, why do we have issue tracking? releases? anything other than what gitosis provides

@lafriks Really? How?

@ptman Well, to integrate both - links to other pages and the own solution - IS modular?

@lukewatts Is the idea of @strk fine to you?

@ShalokShalom I would expect the link to go away once an integrated solution becomes available

The link for generic actions is helpful anyway. You can link to your project page and so on.

And the internal solution will lack functionality which is important to me.

Syntax highlighting is in a very early state.

How is that than about Tooltips?

@ShalokShalom yes, see https://docs.gitea.io/en-us/customizing-gitea/ section "Adding links and tabs" (this was added in #3308)

Thanks a lot ^_^

@ShalokShalom As long as a link to an external service doesn;t become an excuse to put the final solution on the long finger I guess a custom link would be fine..
If I knew Go I'd help rather than just bitching. I'm in favour of anything that gets us closer to a good finalized solution in a reasonable time.

You can link to an internal service as well, so long as you host it yourself?

for me anything like GitHub gists would do but if some improvements can be made like
tags/ categories
or even Medium/ blog style formatting that would obviously be a plus

I think integration into gitea without much complication is best for giteas philosophy

A painless self-hosted Git service.

Noting opportunity to decentralize using BitTorrent, IPFS or privEOS. I like owning by data, but having something more federated for this would be a nice spike to see.

So this request is now more than 2 years old. I wonder whether any progress has been made on this at all?

Nobody are working on this.

Since we now have oauth support, we may be able to build some external thing.

Yes, I think @ShalokShalom 's image is beautiful https://github.com/go-gitea/gitea/issues/693#issuecomment-274277781

@lunny This is Flarum.

I love the idea of the deleted user.
And naming them cups too, like lunny proposed. ^^

So distributed cups. :heart: - :heart:
Share out some cups and let's make a tea party. :D

Throwing in some libraries (in Go) for that purpose:

Very simple core: https://github.com/dyne/binnit
Pretty (&) complete: https://github.com/andreimarcu/linx-server
Yet another: https://github.com/Parimer/spectre

And one that is already distributed:

Stalled in development, IPFS based: https://github.com/beardog108/seedbin

According to Ghost's suggestion, I found a fully decentralized (distributed) Git hosting solution and they may be interested into cooperation. I might ask them today, if you are fine: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

Is there any update on this?
The additional upkeep makes external services a no-go at my workplace, but a gitea cups service would be usable for us.
This feature would be a huge plus for me :)

I think this should be in the roadmap of Gitea.

Yes, please add this!

Would love to see this as well

Yes, please add this!

Would love to see this as well

Please, use the emotions for issue-starter comment:

It will not disturb many subscribed people via email:

And it has more functionality:

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.

I have an unfinished PR name it cups

Common Unix Printing System? Sorry :laughing:

@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.

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

Any news?

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.

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.

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.

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.

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

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?"

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

I like that :innocent:

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.

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 )

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.

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