Pastebin service #246

@laplix commented on GitHub (Jan 19, 2017):

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

@laplix commented on GitHub (Jan 19, 2017): :+1: for this one and I would suggest to name this feature **cups**,, as in cups of tea....

GiteaMirror commented

@pgaskin commented on GitHub (Jan 19, 2017):

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

@pgaskin commented on GitHub (Jan 19, 2017): @laplix That might be a bit confusing with the Common Unix Printing Service. Also +1 as well.

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 19, 2017):

cup? cupi? Or simply Pastebin?

@ShalokShalom commented on GitHub (Jan 19, 2017): cup? cupi? Or simply Pastebin?

GiteaMirror commented

@tboerger commented on GitHub (Jan 19, 2017):

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

@tboerger commented on GitHub (Jan 19, 2017): Or just snippets, I know it's not a fancy name ;)

GiteaMirror commented

@bkcsoft commented on GitHub (Jan 19, 2017):

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

@bkcsoft commented on GitHub (Jan 19, 2017): I still (see gogs issue) think this should be an external service. We could however make it injectable into Gitea 🙂

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 20, 2017):

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

@ShalokShalom commented on GitHub (Jan 20, 2017): Optional features: ) Comment section ) Revisions (History) ) Syntax Highlighting, which is not even available in Gist ) Filter and sorting ![screenshot_20170120_091845](https://cloud.githubusercontent.com/assets/6344099/22141286/9e62de94-def1-11e6-804a-bff909950ddc.png) A lot of +1 and many separately created issue reports about this proposal show a clear picture: gogits/gogs#936

GiteaMirror commented

@bkcsoft commented on GitHub (Jan 21, 2017):

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 commented on GitHub (Jan 21, 2017): 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 :)

GiteaMirror commented

@andreynering commented on GitHub (Jan 21, 2017):

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

@andreynering commented on GitHub (Jan 21, 2017): @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.

GiteaMirror commented

2025-11-02 03:15:26 -06:00

@bkcsoft commented on GitHub (Jan 21, 2017):

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 🙂

@bkcsoft commented on GitHub (Jan 21, 2017): 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 🙂

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 21, 2017):

@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 commented on GitHub (Jan 21, 2017): @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](https://cloud.githubusercontent.com/assets/6344099/22176509/aa91a6de-e00c-11e6-819e-d38c401eb73a.png)

GiteaMirror commented

2025-11-02 03:15:26 -06:00

@ShalokShalom commented on GitHub (Feb 6, 2017):

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

@ShalokShalom commented on GitHub (Feb 6, 2017): May be a nice candidate to fork and adjust: https://github.com/defunkt/gist

GiteaMirror commented

2025-11-02 03:15:26 -06:00

@joubertredrat commented on GitHub (Apr 18, 2017):

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

@joubertredrat commented on GitHub (Apr 18, 2017): Or this, https://github.com/gmarik/Gistie

GiteaMirror commented

@bkcsoft commented on GitHub (Apr 18, 2017):

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

@bkcsoft commented on GitHub (Apr 18, 2017): [defunkt/gist](https://github.com/defunkt/gist) is a command line tool to speak to Gist, [gmarik/Gistie](https://github.com/gmarik/Gistie) is written in Ruby, both are not very relevant here 🙂

GiteaMirror commented

@lunny commented on GitHub (Apr 18, 2017):

A pure golang library is preferred.

@lunny commented on GitHub (Apr 18, 2017): A pure golang library is preferred.

GiteaMirror commented

@joubertredrat commented on GitHub (Apr 18, 2017):

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

@joubertredrat commented on GitHub (Apr 18, 2017): @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.

GiteaMirror commented

@sinnlosername commented on GitHub (Sep 8, 2017):

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.

@sinnlosername commented on GitHub (Sep 8, 2017): 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.

GiteaMirror commented

@ShalokShalom commented on GitHub (Sep 9, 2017):

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

@ShalokShalom commented on GitHub (Sep 9, 2017): I just found today an awesome tool that I want to share it with you: [fssnip.net](http://www.fssnip.net/7U2/title/The-Eff-monad)

GiteaMirror commented

@OmarAssadi commented on GitHub (Oct 19, 2017):

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:

@OmarAssadi commented on GitHub (Oct 19, 2017): 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: [![current amount](https://api.bountysource.com/badge/issue?issue_id=41082392)](https://www.bountysource.com/issues/41082392-pastebin-service)

GiteaMirror commented

@lunny commented on GitHub (Dec 4, 2017):

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.

@lunny commented on GitHub (Dec 4, 2017): 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.

GiteaMirror commented

@ptman commented on GitHub (Dec 4, 2017):

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

@ptman commented on GitHub (Dec 4, 2017): Take a look at gists, there can be several files.

GiteaMirror commented

@techknowlogick commented on GitHub (Dec 4, 2017):

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

@techknowlogick commented on GitHub (Dec 4, 2017): @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.

GiteaMirror commented

@tboerger commented on GitHub (Dec 4, 2017):

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.

@tboerger commented on GitHub (Dec 4, 2017): 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.

GiteaMirror commented

@lunny commented on GitHub (Dec 4, 2017):

@ptman @tboerger @techknowlogick updated my comments.

@lunny commented on GitHub (Dec 4, 2017): @ptman @tboerger @techknowlogick updated my comments.

GiteaMirror commented

@kolaente commented on GitHub (Dec 4, 2017):

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 commented on GitHub (Dec 4, 2017): 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...

GiteaMirror commented

@lunny commented on GitHub (Dec 4, 2017):

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

@lunny commented on GitHub (Dec 4, 2017): @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.

GiteaMirror commented

@ShalokShalom commented on GitHub (Dec 5, 2017):

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

@ShalokShalom commented on GitHub (Dec 5, 2017): Both? So Github Gists together with an own solution? And Gitpin(s) for the internal name?

GiteaMirror commented

@lukewatts commented on GitHub (Jan 8, 2018):

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

@lukewatts commented on GitHub (Jan 8, 2018): *Owner EDIT:* Please keep discussions safe for work...

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 8, 2018):

+1

@ShalokShalom commented on GitHub (Jan 8, 2018): +1

GiteaMirror commented

@bkcsoft commented on GitHub (Jan 8, 2018):

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

@bkcsoft commented on GitHub (Jan 8, 2018): @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: )

GiteaMirror commented

@lunny commented on GitHub (Jan 9, 2018):

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

@lunny commented on GitHub (Jan 9, 2018): Or `.snippets.git` just like `.wiki.git`? And which external service is suitable to do that?

GiteaMirror commented

@kolaente commented on GitHub (Jan 9, 2018):

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.

@kolaente commented on GitHub (Jan 9, 2018): 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.

GiteaMirror commented

@lafriks commented on GitHub (Jan 10, 2018):

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

@lafriks commented on GitHub (Jan 10, 2018): I think single repository could be used and new branch for each paste

GiteaMirror commented

@OmarAssadi commented on GitHub (Jan 10, 2018):

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.

@OmarAssadi commented on GitHub (Jan 10, 2018): 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.

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 10, 2018):

I see it also so, 54

+1

@ShalokShalom commented on GitHub (Jan 10, 2018): I see it also so, 54 +1

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 23, 2018):

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?

@ShalokShalom commented on GitHub (Jan 23, 2018): 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?

GiteaMirror commented

@lukewatts commented on GitHub (Jan 23, 2018):

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

@lukewatts commented on GitHub (Jan 23, 2018): 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

GiteaMirror commented

@lafriks commented on GitHub (Jan 23, 2018):

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

@lafriks commented on GitHub (Jan 23, 2018): Anyway in master version you can add custom tabs to external links in your custom templates

GiteaMirror commented

@strk commented on GitHub (Jan 23, 2018):

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

@strk commented on GitHub (Jan 23, 2018): "external" doesn't necessarely mean "run by someone else" modularity has its advantages too...

GiteaMirror commented

@ptman commented on GitHub (Jan 23, 2018):

@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

@ptman commented on GitHub (Jan 23, 2018): @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

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 23, 2018):

@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 commented on GitHub (Jan 23, 2018): @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?

GiteaMirror commented

@ptman commented on GitHub (Jan 23, 2018):

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

@ptman commented on GitHub (Jan 23, 2018): @ShalokShalom I would expect the link to go away once an integrated solution becomes available

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 23, 2018):

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 commented on GitHub (Jan 23, 2018): 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](https://github.com/fssnippets/fssnip-website/issues/86)?

GiteaMirror commented

@lafriks commented on GitHub (Jan 23, 2018):

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

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

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 23, 2018):

Thanks a lot ^_^

@ShalokShalom commented on GitHub (Jan 23, 2018): Thanks a lot ^_^

GiteaMirror commented

@lukewatts commented on GitHub (Jan 24, 2018):

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

@lukewatts commented on GitHub (Jan 24, 2018): @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.

GiteaMirror commented

@ShalokShalom commented on GitHub (Jan 24, 2018):

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

@ShalokShalom commented on GitHub (Jan 24, 2018): You can link to an internal service as well, so long as you host it yourself?

GiteaMirror commented

@ghost commented on GitHub (Mar 29, 2018):

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.

@ghost commented on GitHub (Mar 29, 2018): for me anything like GitHub gists would do but if some improvements can be made like [tags/ categories](https://github.com/go-gitea/gitea/issues/693#issuecomment-274277781) or even [Medium/ blog style](http://www.fssnip.net/7U2/title/The-Eff-monad) 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.

GiteaMirror commented

@ghost commented on GitHub (Jan 24, 2019):

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.

@ghost commented on GitHub (Jan 24, 2019): 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.

GiteaMirror commented

@irreleph4nt commented on GitHub (Apr 13, 2019):

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

@irreleph4nt commented on GitHub (Apr 13, 2019): So this request is now more than 2 years old. I wonder whether any progress has been made on this at all?

GiteaMirror commented

@lunny commented on GitHub (Apr 13, 2019):

Nobody are working on this.

@lunny commented on GitHub (Apr 13, 2019): Nobody are working on this.

GiteaMirror commented

@kolaente commented on GitHub (Apr 14, 2019):

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

@kolaente commented on GitHub (Apr 14, 2019): Since we now have oauth support, we may be able to build some external thing.

GiteaMirror commented

@lunny commented on GitHub (Apr 14, 2019):

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

@lunny commented on GitHub (Apr 14, 2019): Yes, I think @ShalokShalom 's image is beautiful https://github.com/go-gitea/gitea/issues/693#issuecomment-274277781

GiteaMirror commented

@ShalokShalom commented on GitHub (Apr 14, 2019):

@lunny This is Flarum.

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

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

@ShalokShalom commented on GitHub (Apr 14, 2019): @lunny This is [Flarum.](https://flarum.org/) I love the idea of the [deleted user](https://github.com/go-gitea/gitea/issues/693#issuecomment-457095968). 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

GiteaMirror commented

@ShalokShalom commented on GitHub (Apr 14, 2019):

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

@ShalokShalom commented on GitHub (Apr 14, 2019): 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

GiteaMirror commented

@ShalokShalom commented on GitHub (Apr 18, 2019):

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

@ShalokShalom commented on GitHub (Apr 18, 2019): 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

GiteaMirror commented

@MinmoTech commented on GitHub (Jun 7, 2019):

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

@MinmoTech commented on GitHub (Jun 7, 2019): 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 :)

GiteaMirror commented

@lunny commented on GitHub (Jun 8, 2019):

I think this should be in the roadmap of Gitea.

@lunny commented on GitHub (Jun 8, 2019): I think this should be in the roadmap of Gitea.

GiteaMirror commented

@gemurdock commented on GitHub (Jun 14, 2019):

Yes, please add this!

@gemurdock commented on GitHub (Jun 14, 2019): Yes, please add this!

GiteaMirror commented

@leveled commented on GitHub (Jun 18, 2019):

Would love to see this as well

@leveled commented on GitHub (Jun 18, 2019): Would love to see this as well

GiteaMirror commented

@AlexWayfer commented on GitHub (Jun 19, 2019):

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:

@AlexWayfer commented on GitHub (Jun 19, 2019): > Yes, please add this! > Would love to see this as well Please, use the emotions for issue-starter comment: ![image](https://user-images.githubusercontent.com/6510020/59761683-2123e780-929e-11e9-84ad-fd29cd00672b.png) It will not disturb many subscribed people via email: ![image](https://user-images.githubusercontent.com/6510020/59761741-3f89e300-929e-11e9-86ed-a4b392050ae4.png) And it has more functionality: ![image](https://user-images.githubusercontent.com/6510020/59761796-67794680-929e-11e9-9284-64e58286e837.png)

GiteaMirror commented

@crueber commented on GitHub (Aug 28, 2019):

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.

@crueber commented on GitHub (Aug 28, 2019): 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.

GiteaMirror commented

@lunny commented on GitHub (Aug 29, 2019):

I have an unfinished PR name it cups

@lunny commented on GitHub (Aug 29, 2019): I have an unfinished PR name it cups

GiteaMirror commented

@Mikaela commented on GitHub (Aug 29, 2019):

Common Unix Printing System? Sorry 😆

@Mikaela commented on GitHub (Aug 29, 2019): Common Unix Printing System? Sorry :laughing:

GiteaMirror commented

@crueber commented on GitHub (Aug 29, 2019):

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

@crueber commented on GitHub (Aug 29, 2019): @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.

GiteaMirror commented

@ShalokShalom commented on GitHub (Aug 29, 2019):

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

@ShalokShalom commented on GitHub (Aug 29, 2019): Arch is using PKGBUILDs, opposed to pkgbuild from Apple. Cups instead of CUPS should be fine. I see no struggle

GiteaMirror commented

@BaxAndrei commented on GitHub (Dec 2, 2019):

Any news?

@BaxAndrei commented on GitHub (Dec 2, 2019): Any news?

GiteaMirror commented

@coolaj86 commented on GitHub (Feb 28, 2020):

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.

@coolaj86 commented on GitHub (Feb 28, 2020): # 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. <small>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.</small> # 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.

GiteaMirror commented

@ShalokShalom commented on GitHub (Feb 28, 2020):

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.

@ShalokShalom commented on GitHub (Feb 28, 2020): 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.

GiteaMirror commented

@AlexWayfer commented on GitHub (Feb 28, 2020):

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.

@AlexWayfer commented on GitHub (Feb 28, 2020): Just my life experience: when you're talking about GitHub, you should use PR (Pull Requests) (or [Public Relations](https://en.wikipedia.org/wiki/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.

GiteaMirror commented

@Jirido commented on GitHub (Mar 2, 2020):

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.

@Jirido commented on GitHub (Mar 2, 2020): 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.

GiteaMirror commented

@tjrgg commented on GitHub (Mar 21, 2020):

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

@tjrgg commented on GitHub (Mar 21, 2020): Personally, I don't care what you call it. I would rather see the focus on implementation first.

GiteaMirror commented

@dskrepps commented on GitHub (Apr 23, 2020):

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

@dskrepps commented on GitHub (Apr 23, 2020): 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?"

GiteaMirror commented

@ShalokShalom commented on GitHub (Apr 25, 2020):

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

I like that 😇

@ShalokShalom commented on GitHub (Apr 25, 2020): > I suggest naming the service Gistea and a snippet a Leaf. I like that :innocent:

GiteaMirror commented

@ryanjaeb commented on GitHub (Jun 12, 2020):

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.

@ryanjaeb commented on GitHub (Jun 12, 2020): I would love to have something like the mockup in [this comment](https://github.com/go-gitea/gitea/issues/693#issuecomment-274277781). 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.

GiteaMirror commented

@necrose99 commented on GitHub (Jun 18, 2020):

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 commented on GitHub (Jun 18, 2020): 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 )

GiteaMirror commented

@necrose99 commented on GitHub (Jun 18, 2020):

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.

@necrose99 commented on GitHub (Jun 18, 2020): 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.

GiteaMirror commented

@ptman commented on GitHub (Aug 2, 2020):

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

@ptman commented on GitHub (Aug 2, 2020): One alternative written in go: https://dev.sigpipe.me/dashie/git.txt

GiteaMirror commented

@21h commented on GitHub (Mar 24, 2021):

3 years of naming discussion, no code.

@21h commented on GitHub (Mar 24, 2021): 3 years of naming discussion, no code.

GiteaMirror commented

@gsantner commented on GitHub (Mar 25, 2021):

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

@gsantner commented on GitHub (Mar 25, 2021): 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 😉 .

GiteaMirror commented

@luwol03 commented on GitHub (Mar 25, 2021):

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

@luwol03 commented on GitHub (Mar 25, 2021): One simple solution to use such a feature already is to create a repository named gist and put all md files inside.

GiteaMirror commented

@joubertredrat commented on GitHub (Mar 25, 2021):

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

@joubertredrat commented on GitHub (Mar 25, 2021): @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.

GiteaMirror commented

@21h commented on GitHub (Mar 26, 2021):

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.

@21h commented on GitHub (Mar 26, 2021): > 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.

GiteaMirror commented