Open crapStone opened 3 years ago
+1 for the above.
only one branch exists (pre-push hook to block everything else)
In addition to this, IIRC, GH gists also use hooks to block binary files. Perhaps that is also something for us to consider
Edit: Also no folders are allowed either.
* show a tab with commits/revisions not with as list of commits but with a list of diff-views
I feel like this isn't even really necessary, myself. Certainly a nicety though.
So that we also need a new column in repository table named uuid
.
So that we also need a new column in repository table named uuid.
We won't, as we can use repo_name with and populate it with uuid
URL:
<base-url>/<user_or_organization>/gists/<uuid>
(gists
must be a blacklisted repo name)
Is it possible to implement anonymous code paste? Like https://paste.ubuntu.com/
It seems that in the current design, an account must be logged in
Gists are a way to share information with one or a few files.
You want a pastebin-like service and there is another issue where this is discussed (#693).
Just close this and please discuss further in #693
This is not a duplicate of #693. I want to have gists and not an anonymous text sharing service.
Btw: the discussion in #693 is closed
@lunny did close old issue -> see reason - this proposal here is a better aproach and wont add much extra code etc ...
Gists / Snippets always had a social aspect to them and with Federation coming up, the thought of a (possibly Federated) Gitea snippet feed is cool.
https://gitlab.com/explore/snippets https://gist.github.com/discover
We won't, as we can use repo_name with and populate it with uuid
⁉️ ⁉️ ⁉️
repo_name
is "gists"...
also, my 2c, I think GH uses the commit ID as URL, which IMO is actually easier to handle than "actual routing"
PS: please (if possible, dunno, not a Gitea coder) use .gists
or .somethingelse
as reserved repo name, I mean, something that nobody would possibly think to use, with a dot before or an underscore or something, not something "plaintext"...
@bryanpedini Github uses a fresh repo for each gist, as otherwise when cloning people could discover secret gists, as well if using the commit ID the gist would change location on each change
Hello,
I'm working on a gist program which will have features very similar GitHub Gists but with subtle differences:
Currently, it has a standalone authentication/user management mechanism(i.e people can signup using email IDs), but OAuth integration with Gitea is planned. The full feature list is available on the repository's README.
I would appreciate any inputs you might have :)
@realaravinth are the features listed already implemented or is that a feature-todo in the readme?
@ptman it's a todo list :)
The project is less than a week old but I hope to get posting gists and commenting on it from the web UI working by the end of next week.
The following things are implemented so far:
Account management(credential updates, account deletion, etc.)
But all of the above features are implemented using REST API only. Web UI is in progress.
Are there any news or progress?
@realaravinth @ptman would you mind to discuss this outside of this issue. i am not interested in a third party tool but i want to see gists in gitea. thanks.
I check this issue every day
Cool, good for you, you seem to have time to waste here instead of hands-on the code then...
I want Gist in Gitea
"want"? do it yourself then :) "desire"? you can pay somebody to do it for you "would like"? you can wait like everybody else since here nobody's at your service
Keep the drama for yourself, I'm not capable of programming at this level of Go, hence I'm not here complaining about "when this will be avaaaailableee sob sob sob"...
Thanks.
Hello, I put up an bounty for this request. Hopefully, more users can chip in and incentivize the devs to prioritize this :)
https://app.bountysource.com/issues/100356521-gist-like-repo-type
(PS: I understand gitea is meant to be as lean as possible, this feature may be out of scope, however does gitea supports plugins so that new features can be added?)
UP+
@tahaghafuri thank you for your enthusiasm for this ticket. Please keep discussion of the ticket limited to this issue, no need to open multiple other tickets.
How is this looking at the moment?
I want to applaud you for just going and getting it done. I'll definitely be using yours for the time being. I would prefer that it was tied in to the Gitea auth system, but for my current needs, that's great. Thanks for the advert here.
Not mine but @thomiceli . I would also prefer that it was integrated to gitea instead of separate and duplicating lots of functionality. But it can auth via gitea.
A few years ago, I wondered if this was being worked on. I am surprised not to see it in Gitea today.
A few years ago, I wondered if this was being worked on. I am surprised not to see it in Gitea today.
No, currently no-one is working on this. And tbh please on all you out there: if you want it so badly for years then start working on it yourself instead of pinging this issue every few months.
This works perfectly and can be registered as OAuth application in Gitea
@crapStone
This works perfectly and can be registered as OAuth application in Gitea
... once more: please only bump this issue if this feature is being added into gitea. All people following this issue are well aware that there are 3rd party tools you can plug into it and it kinda works. But we want this as first-party solution inside gitea. Thanks.
I emphasize not bloating gitea ... so this is a perfect solution in my eyes.
why add more maintenance burden if you gain nothing beside copy paste something who is already easy to host too ?!?
I emphasize not bloating gitea ... so this is a perfect solution in my eyes.
why add more maintenance burden if you gain nothing beside copy paste something who is already easy to host too ?!?
Easy: From a administration side, I dont want to run, maintain, configure, test multiple services if I dont have to. Espc checking for updates, diffing config settings, doing the actual update + maybe managing downtime with users.
Also from a user point of view, I hate it to logging into multiple sites, remember multiple urls. It also is a problem when you want a consistent style between the gitea and the gist service; espc when it comes to editing experience. This is better handled inside gitea itself imo.
And if we argue of maintenance burden, we also could argue gitea should not have a ci tool as well, as it might not be needed by everyone, yet it is added since it is a sensefull and good addition. Same applies to gists imho.
AS a gitea maintainer, i dont want to maintain something who i can also run it on a raspbery pi and is setup in exactly 5 minutes - just did so.
and yes I also was against adding ci, just see my profile ... but in terms of adoption more maintainers voted for adding it - but have it equal to other solutions, so on can decide how bloated a gitea installation should get
I’m going to re-open this, as unlike adding CI, the suggested route for snippets is a repo with a different template and a bit more rules around them. Similar to our wiki setup (where it’s an enum in a db row). It’s on my 2024 list of things I’d like to accomplish (not guaranteeing it make it in, as I’d need to work on the PR, but also get reviews, and receive approval from other maintainers).
Okay, I'll go grab some :popcorn: and let you fight over it.
All in good spirits :) I think once my PR is seen, then it'll help fully articulate what I'm thinking, and if not it can be closed.
TLDR: GitHub gist feature for Gitea
Long Version:
Add a new repo type named "Gist" and show them in the webui like a GitHub Gist:
Proposals for implementation:
<base-url>/<user_or_organization>/gists/<uuid>
(gists
must be a blacklisted repo name)RepoType
field to database)gists
and go to gist handling; else go to user repo handling