Live data from Hacker News

Before GitHub

lucumr.pocoo.org

231–240 of 255 posts

Re: Before GitHub

#231

Earlier quoted context omitted.

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.

GitHub was one of the first popular places to 1. not use query params for key entities in the URL 2. to stick user identifiers at the root path! totally unheard of to occupy such an important path at that point! Taken together, this was entirely novel. Next to nobody did this. Twitter was the one other notable example, and that's literally all I can think of. The URL bar was so different back then. It wasn't search b…

Reddit did it, linked in, most social media really, this is all just a throwback to /~user/ paths from apache and other early webservers. I think slashdot used the same convention.

Re: Before GitHub

#232

Earlier quoted context omitted.

GitHub was one of the first popular places to 1. not use query params for key entities in the URL 2. to stick user identifiers at the root path! totally unheard of to occupy such an important path at that point! Taken together, this was entirely novel. Next to nobody did this. Twitter was the one other notable example, and that's literally all I can think of. The URL bar was so different back then. It wasn't search b…

Reddit did it, linked in, most social media really, this is all just a throwback to /~user/ paths from apache and other early webservers. I think slashdot used the same convention.

[deleted]

Re: Before GitHub

#234
post #5
post #2

I absolutely loved Trac. Getting a Trac setup as step 1 in starting a new open source project was just an unbelievable amount of friction. Fun fact: Django is still running on Trac today, and has been for more than 20 years now: https://code.djangoproject.com/timeline (I was not involved in setting that one up, though it's possible I helped get the private Trac that pre-dated it running, I honestly can't remember!)

Weirdly, I also have fond memories of Trac despite absolutely despising it at the time for “doing too much and excelling at nothing as a result”. I guess that award goes to Gitlab now, which I will probably also remember fondly.

GitLab's chief problem isn't that it does too much, it's that they really need to work on UX.

Everything is deeply nested. Many things hard to find. And the UI can be strangely slow or awkward in spots.

I recently worked a job where the client migrated to GitLab from GitHub at my suggestion. And while I think there was on the whole satisfaction with that, it did some with its own frustrations as well.

Re: Before GitHub

#235
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…

You can (and people did) do same kind of tooling based off git protocol and storage. Hell, even one for distributed code reviews. It just... never was something majority actually want so they didn't really get any traction. Issues wise you also get few nasty cases where you really do not want to keep it with project, like having clients send a bunch of screenshots or even videos of triggering some bugs can grow stora…

I tried out like five or six of those back when they were trendy, and they all had one or more of these issues that made them unusable:

* Changes being tied to a commit (akin to git notes) so issues could have different status and comments on different branches. No overall view of the project.

* Using their own branches to separate from code state, which made a huge mess when looking at your branches or git history.

* Using a separate space (like git notes does, I forget what this is called), which isn't included in the standard push/pull.

* All of the above being distributed, issues in your checkout could be very different than someone else's, and now you have to merge those too.

* No non-developer UI for project managers to see or comment on issues.

Re: Before GitHub

#236

> For a while, leaving GitHub felt like a symbolic move mostly made by smaller projects or by people with strong views about software freedom. I definitely cringed when Zig moved to Codeberg! But I now see people with real weight and signal talking about leaving GitHub. The most obvious one is Mitchell Hashimoto, who announced that Ghostty will move. I didn't understand this. I perceive the Zig project and Mitchell H…

Zig catching strays

Re: Before GitHub

#237

> I definitely cringed when Zig moved to Codeberg! If anything Codeberg’s legal structure (being a non-profit) and vision makes it a lot more aligned with the objectives of free and open source projects than GitHub in the long run (which has always been the case but it’s just abundantly clearer today). I think “for-profit corporations providing high quality public services for free” was a zero interest-rate phenomeno…

Codeberg's achilles heel for me is not supporting custom domains for repos.

Re: Before GitHub

#238
post #56

Earlier quoted context omitted.

Yeah, federation is really the sticky bit. It's very frustrating for people to have to create yet another account in order to file an issue or submit a pull request. And on top of that, spam is a huge issue. We've progressively further and further locked down new accounts on gitlab.xfce.org because the spam situation has just gotten so bad. We actually don't allow new "native" account creation at this point, and ask…

We already had federation for decentralized forges: Email But that wasn't hip enough so everyone moved to GitHub.

If you really think the UX of email is the same as the UX of a web-based forge, I'm not sure what to tell you.

You may prefer email over the latter, but I think these days you're in the minority. Your level of derision at this fact doesn't really change anything.

Re: Before GitHub

#239
post #56

Earlier quoted context omitted.

Yeah, federation is really the sticky bit. It's very frustrating for people to have to create yet another account in order to file an issue or submit a pull request. And on top of that, spam is a huge issue. We've progressively further and further locked down new accounts on gitlab.xfce.org because the spam situation has just gotten so bad. We actually don't allow new "native" account creation at this point, and ask…

I really like the idea of distributed forges, but am not familiar with viable solutions for federation. Are there good options available right now? Or at least a not-terrible option? (Edit: Turns out there’s a very obvious and widely used option. git format-patch + git send-email is used to develop major open source software such as Linux, GCC, and Git itself.)

> Turns out there’s a very obvious and widely used option. git format-patch + git send-email

That's fine for pull requests, perhaps, depending on your preferred UX, but what about a bug tracker? CI? Release artifacts?

Re: Before GitHub

#240
post #137
post #132

Earlier quoted context omitted.

fossilised.dev .. maybe british spelling. palaeontology.dev ... too awkward. museum.dev has a sort of "this is dead" ring to it. Ironically what fossils are stored in within a museum is referred to as a "repository".. Well, there's only 2 hard problems in computer science right?

Yeah, museum sounds like dead and rot… However on my small site [1] that’s the name of the fossil repos page [1]: https://hdrz.cc/museum

FYI your cert is expired.
Post reply on HN