Live data from Hacker News

Before GitHub

lucumr.pocoo.org

161–170 of 255 posts

Re: Before GitHub

#161
post #21

I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets , etc) are just so useful to have versioned with your code in one file. I use Fossil for all my freelance work and it so easi…

I wonder what tradeoffs make Git faster for large repository. Though for a long time that excluded large blobs.

None, it just received the help of the vast majority of well-payed SWE to make it that way

Re: Before GitHub

#162
I use a self hosted Gitea instance and it's very simple. I was also surprised when Zig moved to Codeberg and had a big blog post about it, but now over time I start to see the reasons materialize in reality.

Re: Before GitHub

#163
post #27

> Before GitHub, Open Source was a much smaller world. Not that much smaller right-before GitHub and right-after it became available. > but in the number of projects most of us could realistically depend on. Most FOSS I realistically depend on I don't obtain from GitHub actually. > There were well-known projects, maintained over long periods of time by a comparatively small number of people. There were even more not-…

back in the day, I work in a web hosting company. I know every name on mysql devel team. The only reason i subscribe that mail list is: i reported some bugs and need to follows the release. Signal to noise ratio on those mailing list was high. I can't say the same for github or discord

> I know every name on mysql devel team.

That's one project. You did not know every name, or most names, in FOSS generally. Today as well - a project which uses GitHub still needs a mailing list, web forum, chat channel (Matrix/IRC/discord/Telegram/whatever) to discuss and coordinate, and that hasn't changed.

As for whether signal to noise ratio on mailing lists was high - that really depends on the list. I don't see that much noise on GitHub repositories, to be honest - it's not easy to post noise that many people will see, so there's not much motivation for it.

Re: Before GitHub

#164

> What GitHub Gave Us To me one of the clear things that GitHub gave us was a structure around a person rather than a project. To me it felt liberating to quickly create a repository attached to my name than it was to go through the (what felt to me) very serious process of coming up with a project name and reserving it on sourceforge just to get a cvs or svn repository (along with website, mailing lists, issue track…

[flagged]

Re: Before GitHub

#165
post #117
post #18

Earlier quoted context omitted.

I like Gitlab fine by ignoring pretty much everything it does other than host the source code and let me view READMEs in the browser (and for work, also merge requests). In general the more I have to use anything other than those, the more frustrated I get, which was also how I felt about Github in the past. I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, s…

> I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard. Honestly, Gitlab's CI is one of its killer features. I really enjoy Gitlab CI. But, nearly everything else (kubernetes management, AST, AI "DUO", work items, milestones, snippets, workspaces, "operations", "security dashboards", "va…

I don't hate using Gitlab CI once it's set up; I just hate "put shell scripts in YAML to define how this should work". The least annoying experiences I've had with them are when every entry is literally just a single line that invokes an external script; shell scripting is already annoying enough without having to also spend the time to understand a YAML schema for what order they get invoked in and what environmental variables are in scope (not to mention what the implicit inputs are; a few months ago I tried to add a task to run some check on the commit message for an MR, and I found that even on repositories where the merge commit option is disabled in favor of squashing or fast-forwarding, the top commit message is still a merge commit).

Re: Before GitHub

#166
post #126

> What GitHub Gave Us To me one of the clear things that GitHub gave us was a structure around a person rather than a project. To me it felt liberating to quickly create a repository attached to my name than it was to go through the (what felt to me) very serious process of coming up with a project name and reserving it on sourceforge just to get a cvs or svn repository (along with website, mailing lists, issue track…

>To me it felt liberating to quickly create a repository attached to my name If I remember correctly, it was also one of the few places sticking to the now-standard passing of the parameters via path rather than the '?' URL query part. It might not seem like much now, but then the ease and simple beauty of having just github.com/user/repo - not only for web access but also cloning - was definitely some freshness fact…

Definitely not. That's been a thing for at least as long as mod_rewrite has existed (and I'm sure there's prior art). It was common long before GitHub.

Re: Before GitHub

#167
We used bitbucket for years in our academic research group because GH didn't allow private repos. But otherwise it was better to use, so when they allowed that, we made the switch.

Re: Before GitHub

#168
post #49

I really worry about a bunch of people going over to codeberg. Site's already super slow, but apparently it's quite nice when self-hosted Anyone who is able to just plop a forgejo instance on their own machines... please do that if possible!

Can a small project do this and (cheaply) be robust to getting slashdotted?

Which is often the dream for a small project.

Probably yes, Codeberg are very transparent about their infra details and they don't seem wild:

https://codeberg.org/Codeberg-Infrastructure/meta

Re: Before GitHub

#169
post #165
post #117

Earlier quoted context omitted.

> I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard. Honestly, Gitlab's CI is one of its killer features. I really enjoy Gitlab CI. But, nearly everything else (kubernetes management, AST, AI "DUO", work items, milestones, snippets, workspaces, "operations", "security dashboards", "va…

I don't hate using Gitlab CI once it's set up; I just hate "put shell scripts in YAML to define how this should work". The least annoying experiences I've had with them are when every entry is literally just a single line that invokes an external script; shell scripting is already annoying enough without having to also spend the time to understand a YAML schema for what order they get invoked in and what environmenta…

Ah, super valid point.

I use the command invocation to run python scripts. I tend to believe that CI is just a controlled way to do things you would do locally.

Re: Before GitHub

#170
post #36
post #21

I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets , etc) are just so useful to have versioned with your code in one file. I use Fossil for all my freelance work and it so easi…

Now is a great time for somebody to buy fossilhub.com and create a new community.

I already saw fossilhub.io mentioned in this thread, actually.
Post reply on HN