Live data from Hacker News

Before GitHub

lucumr.pocoo.org

81–90 of 255 posts

Re: Before GitHub

#81
post #52

It's fun to read stuff like this and then reflect on the journeys of the projects I've been involved with. Most of my open source work has been done with self-hosted infra. My main example is Xfce: back when I started with them in 2004, we had a SVN server, using (I think) CVSweb's then-new SVN support for the web interface, and... maybe that was it? My memory is telling me that I set up Bugzilla at some point after…

xfce is integral part of my life. Thank you for working on it

Re: Before GitHub

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

When I tried Fossil it had things weirdly separated. I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.

This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature.

Personally speaking though, I don't want things automagically closed GitHub-style based on parsing a check-in comment. An issue ought to be closed with intention.

Re: Before GitHub

#83
post #82

Earlier quoted context omitted.

When I tried Fossil it had things weirdly separated. I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.

This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature. Personally speaking though, I don't want th…

> I don't want things automagically closed GitHub-style based on parsing a check-in comment.

Sure, I get that. I was just disappointed that none of the project management stuff seemed terribly integrated in any way from my brief review. It seemed like opportunities there that were not taken.

Re: Before GitHub

#84

> 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]

[flagged]

Re: Before GitHub

#85
post #34

Earlier quoted context omitted.

[flagged]

Huh? The usual pattern is that experiments belong to a user and then they graduate to having their own org iff they grow enough maintainers for that to make sense. How is that toxic or self-centered? It's just like "here's a place to do low-stakes experiments in public view". It's not particularly about ego or selfishness or whatever.

“Organizations” didn't exist until GitHub was already popular and entrenched, and it got popular and entrenched by centering the person developing the code instead of the code that was being developed: https://github.blog/news-insights/introducing-organizations/

And they weren't free until 2020: https://docs.github.com/en/get-started/learning-about-github...

Re: Before GitHub

#86
post #64

Earlier quoted context omitted.

> His post is a response to Mitchell's, from just a few hours ago. Is there a link to Mitchell's post somewhere? I can't find one in the article.

https://mitchellh.com/writing/ghostty-leaving-github

Thanks!

Re: Before GitHub

#87

> 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]

Bruh.

Re: Before GitHub

#90

> 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]

The most insane response I've ever read here, so far.
Post reply on HN