For personal, single-person projects I went back to a bare (git init --bare) repository on my SMB share.
I tried gogs and gitea, and at some point, I encountered a bug where the cpu would spike to 100% constant load, and make my instance impossible to use. I also didn't want to run Gitlab on my NAS for performance reason.
I'm pretty happy now, with one system less to manage (although I don't want to discourage anyone to have a look at Kallithea - maybe it suits your needs!)
Aha, '--bare': what does that do? I always just type 'git init'.
Let me do a little git bashing, OK? Sorry for this, but it so nicely documents my initial problems with git when I started a few years back. And it still occasionally (like right now) makes me shake my head in disbelief:
> man git-init
Searching for --bare gives me:
> --bare
> Create a bare repository. ...and how GIT_DIR is set...
You don't say!!
I search for other occurrences of 'bare' in that man page, but after skipping those in the synopsis and the help text, it says:
> Pattern not found
So bare = bare. Tautological documentation. It's all obvious, right?
What --bare really does is to put what git would normally put into the '.git' subdir into '.'. I tried what it does, that's how I found out.
Git is great, but please never claim that it is intuitively documented.
The man pages are indeed not great. I usually invest a bit more time reading the git book, it explains what a bare repo is a bit better: “ a new bare repository — a repository that doesn’t contain a working directory.” From the “setting up git on a server” chapter (https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git...) which I think is the main reason why one would use a bare repo.
That said I concur and don’t think anyone would make such a claim about git documentation.
A bare repo has only Git's own data structure files. It's basically the contents of a non-bare repo's ".git/" directory, without a checked out working copy of all the files that are contained in the repo. The files are all still there but stored inside Git's database and not in the filesystem in the normal way.
The advantage: you can push commits to a bare repo. It's the kind of repo you'd put on your remote dev server. If you try to push to a non-bare repo, you'd get an error message like:
remote: error: refusing to update checked out branch: refs/heads/dev
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
...which is a long way of saying "don't do that". The disadvantage is that you can't cd into a bare repo and use "ls" and friends to browse around.
So here's the even shorter answer:
Make a bare repo when you only want to push to it but not work inside it, say because you're making a shared repo for you and your friends to work on together.
Make a non-bare repo when you want to work inside it but not push to it, say because it's a project you're developing on your laptop.
git user interface design is a disaster. It's no wonder it's hard to document (this is a bit orthogonal to your point...).
Git has an extremely complex data structure/state: It's a forest of DAGs (commits in distributed repos), with labels on them (branches), that have specified relationships (remotes), as well as an index and a stash per DAG. All of this on top of the working directory (and .gitignore if you want).
Of course these individual elements are mostly necessary to enable complex workflows. But simple workflows interact with all of these elements too in complex ways. This complexity is neither hidden behind a sensible set of UX abstractions, nor are they cleanly exposed to the user with a set of clean elementary operations to work on them...
Mercurial works more or less the same way, and yet I find mercurial UI much simpler.
The main difference, I think, is that mercurial has stronger opinions on how you should manage your repository and hides everything that doesn't fit its views behind extensions.
Really, I don't understand how git managed to become so popular. It is really good and I like it a lot but it really takes time getting used to. I screwed up a lot before getting competent with it, and I still screw up from time to time. It didn't happen with cvs, svn and mercurial.
It makes me think of Perl. Powerful and messy, I like if for the same reason I like git. But while Perl is on the way down, progressively replaced by cleaner, more opinionated alternatives, git is becoming a de-facto standard.
I’ve always believed that it was GitHub that allowed git to win out.
In addition to that, I suspect it was the very fact that Mercurial had more features, specifically an in built web server that allowed you to easily share your repo, led to GitHub being created with git and not mercurial.
The way I look at it, Mercurial made it extremely easy to self host a repo. So there was no need for a 3rd party centralized service to share your mercurial repo. That wasn’t the case for git, so something like GitHub was needed.
But the centralization in GitHub also allowed them to add more social features, which allowed git to spread more widely.
[Shameless plug] If all you need is the ability to manage a bunch of personal repositories hosted on your ssh server, you may want to try "reposetup", a minimalist, shell-based, repository manager: https://github.com/agateau/reposetup
While that is true, I did try searching the main git man page for GIT_DIR and found it said the following:
> GIT_DIR
> If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository. The --git-dir command-line option also sets this value.
That said, manuals are typically written like this, meaning that for terms one isn't already aware of, there is a need to search through the index to find its meaning and them piece together the information.
> git init --help > OPTIONS > --tiramisu > Create a tiramisu repository. If GIT_DIR environment is not set, it is set to the current working directory.
Ok, so can you tell me what is a tiramisu repository?
Are you saying you don't know what the word "bare" means? Is that the confusion?
Googling for the definition I find "Bare: without addition; basic and simple."
And yes, I can. A tiramisu repository is a fictional repository that is not at all mentioned the very helpful help section of git init. While completely fabricated, the tiramisu repository is one of the best tasting repositories git can produce.
If the directory containing the git objects is not set, it is set to use the directory you normally find a working tree in. This is pretty straightforward once you know the basics of git, and I can’t imagine anyone would be creating a repo holding only the objects (a remote only repo you simply pull/push to/from) until they know the basics of git.
git is split up in many man pages. That's generally a good thing, but you sometimes have to search or look at more than one man page to find what you are looking for.
You could try
> man -K "bare repo"
to search all man pages for that string, and you'll find that
> man git-clone
has the information you are looking for:
"--bare: Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the <directory> itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree."
If you have Internet connectivity, Google is also an option. Among the first hits should be the book "Pro Git", chapter "4.2 Git on the Server", which begins with a concise explanation what a bare repository is.
> ... but you sometimes have to search or look at more than one man page to find what you are looking for.
Well, yes, that's one of the problems. I am saying the docs are unintuitive, and now you are confirming that.
For 'git init --bare', I look into 'git-init' and search for '--bare'. That's what I do, that's intuitive to me. And that's not where the info is. Is all I am saying.
Another good option if you need to start moving your repos to other machines or want to back them up is using rsync.net. They added git support many years ago and it's just like setting up a bare repo on a remote SSH host but all managed by rsync.net: https://blog.kozubik.com/john_kozubik/2010/02/git-and-subver... Once your repos are there then accessing them from anywhere is just a git-ssh clone away, just like a private github repo.
If you just want to use for personal single-person projects fossil [1] and mercurial [2] may be a better choice, given both come with in-built web interface. Just run hg serve or fossil server or fossil ui. No need any external platform or program.
I personally use Pagure[1] for mine. I use it because Pagure is fairly easy to install and maintain and it's packaged in virtually all major distributions[2][3][4][5]. I can easily develop my personal projects in them, have my own kanban boards for task tracking, and all the project data is stored as Git repos, which makes it easy to archive and replicate (with full project history).
I've got a personal instance running on openSUSE in a tiny 1 vCPU+1GB RAM VPS, and it works really well. It's fairly lightweight on resources, too (my VPS instance rarely sees significant load).
I've been using fossil for personal projects, for the last 3 months. The all-in-one aspect is great, and it's literally 2 commands to start a server. When I need a new remote repository, I just have to copy the .fossil file on my VPS. The only thing I don't like is the issues management, which isn't user-friendly at all.
I didn't know that mercurial had a web interface, I'll certainly take a look this week.
Gitea maintainer here :) Is there an issue/PR you can point me to? I'd be happy to take a look and see if we can get it on the roadmap. We're working on improving testing strategy to reduce new bugs. We don't include front-end in our tests right now, which is imo our biggest issue. Would love some help with the this. We just support so many platforms, databases, and config options it's difficult to catch everything. It's a great project to work on and there is plenty of room for improvement!
Thanks for your work on this nice piece of software!
We created our small company last year and it has not only been our VCS (nicely integrated with Drone for CI/CD) but we also based our SSO on it (we had to add a homemade OIDC/OAUTH proxy though). I'll hopefully soon find the time to clean-up the code of said proxy and of the helm chart we wrote in order to propose a contribution to this nice project.
I deployed and run Gitlab for a large company and have used it in other contexts in the past. While Gitlab's feature set is obviously much wider, Gitea is a nice trade-off when a lighter footprint is desired.
Thanks again!
Hi. You all but shut down my criticism of the mirroring system and the fact that it fails outright if Gitea dies in the interim - sometimes even due to Gitea deadlocking itself - and insisted this was SQLite's problem and not Gitea's.
That's the one example I'm referring to.
Since then, we faced a number of UI bugs that we just didn't bother to report since most other attempts at reaching out were rejected as "not our problem".
> and the maintainers seem to disagree they exist, which is a shame
Does this extend also to the case of when someone submits a pull request to them, or only for issues that people file?
If the former then it is truly problematic. If the latter they may be simply overworked/overburdened by the volume of issues that are being filed, and could need more people submitting pull requests instead of opening issues.
> If the latter they may be simply overworked/overburdened by the volume of issues that are being filed, and could need more people submitting pull requests instead of opening issues.
Although merging and reviewing a pull request can also be quite time-consuming. If you are already overworked, it might add to the problem. I'm happy that none of my open-source projects went through the roof. I won't be able to manage it alone.
I enabled SSH on my NAS and use git over ssh for some stuff that never leaves my home network. For stuff I share a bit more widely I use git-shell over SSH with a few scripts to create and list repositories on a 5$ VPS.
But for bigger projects I now use github as I missed CI and pull request review flows, even for my own work
> I encountered a bug where the cpu would spike to 100% constant load
A bit off topic - but is that an underlying problem with go-lang projects? I've seen a similar problem when using a couple of other go-lang tools, where the entire CPU hits 100% and locks the machine. Too many channels/threads perhaps?
How does this replace a Git web interface, though? I guess you could have it serve simple index.html pages but I don't see how you're going to get code browsing and issues and PRs, except maybe locally on your machine.
> How does this replace a Git web interface, though?
It doesn't. And it shouldn't.
I don't need code browsing on my SMB repo because, well, I'm the only one working on it. And even if I weren't, it'd be kinda fine anyways. I don't have the extra layer of security, but I don't need that either: I already need credentials to connect to my SMB share.
PRs - well, single project. It's just for me, so merging my own feature branches seems fine.
Issues are indeed an "issue". I simply track them in a markdown file. Whatever floats your boat should be fine, though. Combined, for me personally, it works better than managing a platform I don't really need.
I've gotten pull requests for some of my personal single-person projects. It's very appreciated, and I doubt they would come as much if the only interface was a read-only git repo and an email address.
I've got some open-source projects as well that are hosted on GitHub, where I accept (and appreciate!) pull requests. But there are some projects I work on in my spare time, just for the fun of it. I don't need feedback on these. At least, not yet. For this, it's just nice to have something "locally", yet automatically backed up on my SMB share.
I'm pretty happy now, with one system less to manage (although I don't want to discourage anyone to have a look at Kallithea - maybe it suits your needs!)