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.
Before GitHub
161–170 of 255 posts
Re: Before GitHub
#162Re: Before GitHub
#163> 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
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…
Re: Before GitHub
#165Earlier 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…
Re: Before GitHub
#166> 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…
Re: Before GitHub
#167Re: Before GitHub
#168I 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!
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:
Re: Before GitHub
#169Earlier 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…
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
#170I 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.