Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitea – Alternative to GitLab and GitHub

gitea.io

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Gitea – Alternative to GitLab and GitHub

#91

Post by Freak_NL »

falsedan wrote: post #87
Freak_NL wrote: post #18

Earlier quoted context omitted.

You could open a well-worded issue for it (“Gitea code base should be hosted on gitea instance”) and track that. There is a chance that the developers will close it as a WONTFIX of course.

> well-worded issue Your example is not well-worded; it's a demand. I'd expect a well-worded issue to share some story about how you were working to achieve some goal, so you tried setting up gitea to self-host the gitea repo, and were surprised that it didn't work (and share the errors etc. that you saw). Then the devss can prioritise your issue by understanding how blocked you are by the missing behaviour, and even…

The phrase between parentheses was meant as an example of the succinct title of such an issue, not the hopefully polite and well-worded body explaining why.

Re: Gitea – Alternative to GitLab and GitHub

#92

Post by saltedmd5 »

tome wrote: post #42
joefreeman wrote: post #36

Earlier quoted context omitted.

Isn't 'origin' (not 'master') the convention you're referring to?

Both "origin" and "master" are conventions. They are promoted by the tooling that gives them a sort of default status.

In the context of the original post, he is referring to origin (the convention for a default remote repository), not master (the convention for a default branch).

Re: Gitea – Alternative to GitLab and GitHub

#93

Post by huntie »

falsedan wrote: post #72
huntie wrote: post #51

Somewhat related, I've been thinking of how to speed up git on hosts with limited resources. As an example, the firefox repo has a 275MB index file which has to be loaded whenever you want to read the repository. On a host with 1GB of ram this doesn't work so well. I think that storing repositories in loose format would make them much faster to read, but maybe I'm missing something. Any thoughts?

The index is just a cache of the metadata of files in the working directory; changing how the objects in the repo are stored won't speed up a 'git status'. When you say 'read the repo', it makes me think you're more interested in the behaviour of cloning from a remote. Loose objects would avoid the need to inspect packfiles, but… that code's all written in C and mmaps the contents & does fast seeks. Most likely the s…

I was thinking about this from the perspective of a server like Gitea. What I meant by 'read the repo' is retrieve objects like commits to display them to the user.

So on the server you should only ever have packfiles, and in order to efficiently read packfiles you read the index (idx) file. I'm not positive, but I think that this file needs to be read in its entirety in order to access an object. Even if you don't have to read the whole file, it's probably best because you generally read more than one object at a time (e.g. if you display a list of files in HEAD you read the commit pointed to by HEAD, read its tree, and read all of the blobs in its tree).

My thought with using loose files rather than packfiles is that you wouldn't suffer the memory overhead of lookup, you just open the file at `objects/some/object` and parse it.

The real solution here is probably to get a server with more RAM and cache repositories. I'd be interested to hear what GitHub does.

Re: Gitea – Alternative to GitLab and GitHub

#94

Post by huntie »

tome wrote: post #61
huntie wrote: post #51

Somewhat related, I've been thinking of how to speed up git on hosts with limited resources. As an example, the firefox repo has a 275MB index file which has to be loaded whenever you want to read the repository. On a host with 1GB of ram this doesn't work so well. I think that storing repositories in loose format would make them much faster to read, but maybe I'm missing something. Any thoughts?

What operations do you want to do? Have you considered a shallow clone?

I forgot to mention that I'm thinking about it from the perspective of a server like Gitea. So I want to retrive objects like commits and blobs from the repository.

Re: Gitea – Alternative to GitLab and GitHub

#95

Post by saltedmd5 »

viach wrote: post #24

Why it's considered to be an alternative? Github is all about social networking for developers, not code hosting, or am I wrong?

You are wrong.

GitHub is a hosting platform for git repositories, which has collaboration tools (such as issue tracking and code review) built into it.

Re: Gitea – Alternative to GitLab and GitHub

#97

Post by mlthoughts2018 »

sago wrote: post #55
tjoff wrote: post #43

Earlier quoted context omitted.

For the vast majority of use cases centralization is an essential feature. You want that single source of truth, then you can have tons of branches etc. outside but without that single source everything falls apart if you are a team of more than one person. I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my wo…

> Pulling code from random developers machines might sound pretty neat Isn't that just a straw man argument? To the extent that it applies to distributed version control, it seems like an invented problem (i.e. I don't know anyone who uses a dvcs that pulls from 'random' developers). To the extent that it is true (we are all probably guilty of using code from developers we don't know and have not properly vetted) it…

I interpreted “random” in the parent comment to mean “ad hoc, but planned”. Meaning, not random, untrusted or unknown engineers, but engineers from an obvious trusted group (like my team), just accessed in an ad hoc manner.

The point being that short of choosing a convention for which person’s copy (or which machine, etc) counts as the primary source of record (which would then just be poor man’s centralization with the admin costs and maintenance of any centralization tools now a burden on the team rather than a third-party product), then interacting in an ad hoc way with even just my known team’s set of distributed clones of the project turns into a bookkeeping problem nobody wants.

I can also imagine a non-centralized model can lead to many more complicated workflow failure modes. I’m just thinking about how often novices get stuck with rebasing errors or squashing commits incorrectly, and bikeshedding arguments over whether it’s ok to ever revert master or if you should intentionally keep mistakes in the history and correct with new commits. I can imagine it being even worse when there are fewer conventions, since conventions are often the only way to avoid these bikeshedding debates about preferred git hygiene methods.

Re: Gitea – Alternative to GitLab and GitHub

#98

Post by ldehaan »

maconic wrote: post #32
sago wrote: post #23

Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design. Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of p…

Independent of Gitea (which I have nothing to do with nor have any relationship with anyone involved). Your comment "It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design." worries me. Yes, technically accurate, just as notepad, webstorm, atom, vi, emacs, etc. also don't need any 'host'. If you aren't working with multiple authors, a local laptop with git plu…

you could use ngrok to expose yourself temporarily for distribution

Re: Gitea – Alternative to GitLab and GitHub

#99

Post by LamaOfRuin »

sago wrote: post #55
tjoff wrote: post #43

Earlier quoted context omitted.

For the vast majority of use cases centralization is an essential feature. You want that single source of truth, then you can have tons of branches etc. outside but without that single source everything falls apart if you are a team of more than one person. I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my wo…

> Pulling code from random developers machines might sound pretty neat Isn't that just a straw man argument? To the extent that it applies to distributed version control, it seems like an invented problem (i.e. I don't know anyone who uses a dvcs that pulls from 'random' developers). To the extent that it is true (we are all probably guilty of using code from developers we don't know and have not properly vetted) it…

By random developer's machines they meant the actual machines. You can technically pull from another developer's (random or not, but anyone with the repo) actual laptop rather than going through an intermediary.

That was in fact one of the arguments a few true believers used in favor of DVCS when it was still a novelty.

The think I think truly gives developers comfort, in addition to all the nice features it makes simple, is LOCKSS (Lots of Copies Keeps Stuff Safe). When everyone has a full copy of the repo, even if you generally work through an intermediary, the central repo being blown away or taken control of by a bad actor doesn't mean you need to reconstruct the history of the code from whatever single snapshot checkouts individuals happen to have.

That said, I will agree that the workflows enabled, as well as the power of a common platform, are probably what really let git and github become the new default.

edit: Also I imagine being able to paw through the entire history and bisect entirely locally are vital features for a small (but essential especially of open source) minority of developers.

Re: Gitea – Alternative to GitLab and GitHub

#100

Post by criddell »

viach wrote: post #24

Why it's considered to be an alternative? Github is all about social networking for developers, not code hosting, or am I wrong?

I'd be interested to see some numbers about projects that actually leave Github. Other than FUD about the Microsoft acquisition, has something changed on Github that is making people talk about leaving? Why run away before there's a concrete reason?
Post reply on HN