Pastebin service #693

Closed ShalokShalom closed 2 years ago

Gitea version (or commit ref): all
Git version: all
Operating system: all
Database (use [x]):
- [x] PostgreSQL
- [x] MySQL
- [x] SQLite
Can you reproduce the bug at https://try.gitea.io:
- [x] Yes (provide example URL)
- [ ] No
- [x] 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!](https://www.bountysource.com/issues/41082392-pastebin-service?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).

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

screenshot_20170120_091845

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:

screenshot_20170121_190545

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 ?

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.
Every type repository could have different tabs(we store them on repo_unit). So every repository could load their units to tabs.
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.
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.
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.

go-gitea / gitea

Pastebin service #693

Description