Perhaps I'm an odd duck (I am) but I think current git hosts are no longer meant for hackers and I really wanted a git host that is and that's why I'm building gitern.
Gitern is just getting started and only has essential features today but we already have a few differentiators:
- all auth is done with ssh keys (no password or email required)
- arbitrary repository paths allowing for (1) familiar namespacing and (2) access control (eventually)
- a cli-first ui
- private repos are default
I think better tools make for better hackers and I think git hosts can be a lot better.
I'll be in the comments if anyone wants to ask questions or scold me or something :). Very very open to feedback!
One of the main authors apparently claims that he is re-writing the core intensely. Hopefully that will go well and we'll see it re-surface, though it carries all the usual risks of vaporware.
I'm really hopeful we'll see Pijul or something like it take off at least with "hackers." The promise of a robust patch theory is pretty exciting!
nice to hear that but honestly, "re-writing the core" for 6 months - not a good sign at all :(
I use pijul intensively for my own pet project and now feel insecure about that.
I started migrating the library tonight, because, moving forward, we'll be adopting it (btw, I just discovered it has some recent changes worth reviewing). We also maintain native Rust libraries for interdiff (wip), combinediff, splitdiff, lsdiff, and patch. It's late now, but I'll add it in with those libraries in https://github.com/changeutils.
If you'd like to add support in Gut for existing Pijul-managed sources, you could help work on the migration feature. We plan to support compatability with other patch-oriented version control systems, as well as with Git. It'll make history when we add that feature.
VCSs can seem a lot more complicated than they need to be. Getting back to the basics, as we're doing with Gut, really illuminates a lot of obscured opportunities. As a few other parts of the Speakeasy Engine soon come together, even a Web UI for version control management will fit well in our coding toolset.
Hi! main author here. I'm about to release it, should be ready in the next few days. Most of the 6 months were spent testing and debugging it, actually.
Hey, I know gitern is cli based, but I wanted to compliment you on the design of the gitern.com site. Love the colors, artwork, everything. Very minimalistic and tasteful.
Looks very nice, minimalistic. Just wanted to make you aware of ForgeFed [0]. Don't know how it fits in your approach and that depends on features you planned, but maybe just like Vervis [1] you could be one of the early adopters and become the forge of choice on the fediverse (they love this stuff, just like they also embrace Sourcehut).
Mostly because you have or anticipate having git-specific needs other than backups, like having a central collaboration point as part of your git workflows. You can use gitern like a backup service, but that is a subset of what is intended.
(I don't use that rsync service so I'm just guessing as to how you use it. If you can provide more context, I might be able to help further.)
At the moment, the feature set around git workflows is not more than just providing authorized access for several users to a git repo itself but I'll be providing more features around this soon in a way that improves on what currently exists on git hosts.
I think the point is not about backups. It is really, really easy to set up a remote git repository. Everything is nicely documented in chapter 4 of Pro Git [1]. Because a git remote is nothing more than a plain directory, you could serve a git repo anywhere you could store files, even on your own disks.
If multiple people need push access to a private repository, just serve a central repository as on a VPS and use SSH for authentication. I am not sure if there is a reason to use a third party hosting service for this, especially when hosting private repos.
Edit: I don't mean to dismiss your comment. I just mean to say I'm obviously comfortable doing what you described but it's not a trivial amount of effort even if it is conceptually straightforward.
It's a little bit of work, but really it's surprising how well Git works with the dumbest servers. I run a number of Git mirrors off a $5 VPS served from a folder that I run python3 -m http.server in; it's literally just that and it works beautifully.
Does rsync.net give me the ability to stop people from force-pushing to `master`? My understanding was that it was aware of files but had no concept of Git.
Assuming you're using the chore chart with others, you are now assigned the chore twice rather than once in the rotation of the chore. It's no more than a weak disincentive for missing chores. (A better disincentive would be fines as I write about here https://keyankousha.com/the-best-chore-chart-in-the-world.ht... ... which I haven't implemented because I didn't need them in my housing situation as the weak disincentive of more chores worked fine.)
Thanks for the response. How do you get assigned twice though? Once a task is assigned I don't see a way to be able to assign someone a second time. Does it happen via a menu that's only available after someone has missed an assigned chore?
Also, any interest in releasing it as an open source project? :~)
Hmmmm it's probably best demonstrated with an example: if you have users a b and c, a normal rotation of a chore would be a b c a b c a b c ... and so on. If user b has 2X, the rotation would be a b b c a b c ... Does that make sense?
Assignment and rotation happens automatically. A chore is setup with a frequency, etc, then as users are assigned they are notified and they only need to intervene when they do the chore.
Yep, I understand what happens after B has 2X, but I'm confused about how you can get to 2X in the first place. If you go ABCABB then it doesn't look like C gets 2X, it looks like B gets O instead.
How does a mate end up with 2X in the first place?
Also: are there chores where everyone is assigned? Like "pay your rent" where it's important that everyone does it?
When you don't do your chore, you're assigned the chore for an additional contiguous period. e.g. Floors are set to be swept every week. You didn't sweep the floors on time this week, so now you will sweep the floors the next 2 weeks.
There are group chores, but there aren't penalties for individuals missing group chores so that's a use case hole.
Shoot me an email to discuss more: keyan@choremate.co
Competition is not a bad thing, but I'd definitely recommend that people check out Sourcehut.
Sourcehut ticks all of the boxes for a well-run project: Open Source, good engineering, sensible financial plan, excellent maintainer who works well with others, and constant, sustainable progress.
Sourcehut is also accumulating lot of support for niche things that other providers don't support at all: e.g. it is a Mercurial host as well as a Git host, and the CI supports BSD OSes.
I'm not familiar with sourcehut but thank you for sharing. I'd say if you're using a git host you're already happy with you should keep using it for sure.
It has its own very hacker-oriented aesthetic and tries to keep the various components it provides separated so for things that are "close enough" you might be able to bootstrap off their tools.
Also, the concept of a CI system where a failed build sticks around for a while and lets you ssh in to figure out what went wrong is -way- cool.
I'm not really looking for a new git repository hosting service but this seems cool. I was a bit disappointed that I had to download a cli tool after signing up. It would be cool if you could do all the management non-git operations via ssh and without any additional client software
Edit: Eventually the cli will provide a lot more (and self document what's available) so I do recommend using it, but you can happily get along with these "raw" commands for now.
Thanks! I agree. I want to provide more client-side options eventually (e.g. a static binary or pick your language flavor cli), but had a bunch of tradeoffs to consider for first pass. I'll likely open source the client side and keep the ssh api backward compatible, so perhaps this can happen soon.
Re: ssh-based chat. I found that post very very early on while exploring gitern as just an idea! Very formative of gitern.
These should absolutely be documented on the site!
When I looked at the CLI source I almost walked away. 112MB spread across 12k files from a developer I don't know is _way_ too scary to trust with access to my SSH private keys. Being able to manage it without that CLI tool, though, makes it something I might try out.
Hey, first of all, cool project! Although I certainly see the romantic appeal of "no email or password, just ssh key" and "the cli is the ui", other than for solo hackers I think you need a way to visualize the changes of a Pull Request (or Merge Request like in Gitlab) and do a code review, add comments, etc. Or at least Patch Review like in sr.ht
I actually think that would be useful even for a solo hacker. Other features would also be welcomed, like CI/CD and tickets to track new features and bugs, but you can always integrate with a third party service for that.
Also, unless I'm missing a key feature, I think for the use case you're appealing to you could just have a repo in a VPS or rsync.net. And the comparison with Dropbox doesn't apply here because dropbox is for the masses, and gitern ia for hackers, any hacker would know how to set that up. Finally with keybase you can create encrypted git repos. You can, manually set encrypted git repos on a VPS but it's difficult, keybase does it hassle free. You can also self-host something like gitea/gogs or gitbucket, or even gitlab.
I was expecting a static binary when I downloaded the CLI, but I got a huge load of node.js files and modules. Consider packaging your node.js application up, I haven't tried it but https://github.com/nexe/nexe looks promising.
Thanks for the link. v0 cli was written in gerbil scheme (http://cons.io) but I couldn't get it to statically link on linux so I'd still have deps in the form of dynamic libs. Then I found oclif which while depending on node has a lot of what I need and will allow me to ship/iterate faster ... If the spec/features/api was fixed, I'd write the thing in golang if only for the static binaries and cross compiling but it's a relatively joyless/cumbersome language IME, so node for now at least.
I was writing a similar cli tool [1] to manage the git repositories on my own server. If you want portability, it should be fairly easy to write the cli interface in plain sh or bash, especially when most of the operations could be done on the server side. I am not sure if there is a reason to use a compiled language for this.
Thank you! I have a mostly empty blog http://keyankousha.com (I have some drafts in the pipeline but I don't have a good writing habit yet). Twitter is a little more active @k00bideh
Awesome! That's EXACTLY what I'm going for. I kept using github and having this feeling of "this doesn't feel like it was built for me."
Current git hosts don't feel like they were made for programmers which is nuts! Even for the most essential and basic actions (all of what gitern provides at the moment), they feel kludgy. My intent is to carry a programmer-first approach for all needs programmers have around git hosts. I have SO many ideas on how to do this.
If you couldn't tell, I'm very happy to hear you had a positive impression lol. Thank you!
Yes, it is encouraging to see that people are still interested in creating brutalist interfaces.
I'm not sure how it would fit a professional workflow, since that would require your server to call a web hook whenever somebody merges to a given branch, but it would do fine in an amateur workflow where I set up my own CI/CD using local hooks.
And you've already made a cli, so creating and listing pull requests will be easy. Actually quite powerful, I'm sorely missing this feature in bitbucket.
Thanks. Repositories are stored on an ext4 filesystem. I do backups every 12 hours currently. No additional replication is performed but it is something I want to do.
You'll probably want to look into using CEPH/similar when/if the service starts to get busy. Partly for redundancy but also if all your repositories are on a single shared disk you're gonna hit I/O contention if many people are pushing/pulling at the same time - even more so if you get any CI system wired up.
Is this for script kiddies that just want to be called a hacker? All the hackers I know realize Git is already decentralized and all you need is an SSH server.
You: Is this for food kiddies that want to be called foodies? All the foodies I know realize dumplings are just sheets of dough wrapped around a filling.
These 2 don't relate at all. By your definition, the service might as well be a platform for disc jockeys because computers and speakers both use electricity.
Perhaps I'm an odd duck (I am) but I think current git hosts are no longer meant for hackers and I really wanted a git host that is and that's why I'm building gitern.
Gitern is just getting started and only has essential features today but we already have a few differentiators: - all auth is done with ssh keys (no password or email required) - arbitrary repository paths allowing for (1) familiar namespacing and (2) access control (eventually) - a cli-first ui - private repos are default
I think better tools make for better hackers and I think git hosts can be a lot better.
I'll be in the comments if anyone wants to ask questions or scold me or something :). Very very open to feedback!
Cheers everyone