Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SDL Moves to GitHub

discourse.libsdl.org

Post reply on HN
Print view View original

41–50 of 270 posts

Re: SDL Moves to GitHub

#41

Post by pdw »

livvelupp wrote: post #24
d1zzy wrote: post #12

Earlier quoted context omitted.

Seems to be popular at Facebook.[1] Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things: - hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will au…

What's the other options besides hg if it ain't git?

darcs is still actively developed and it has a niche in the Haskell community.

Ubuntu might still use Bazaar.

Re: SDL Moves to GitHub

#42

Post by ocdtrekkie »

swatson741 wrote: post #18

I've worked on SDL although I haven't contributed any code. Partly because it isn't convenient to contribute and partly because I felt that the work I did wasn't significant enough to merit jumping thru the hoops to contribute. The move to Github is a very welcomed change. > One reason we hadn’t considered a move to GitHub before now is that this project has had a policy of owning all its infrastructure. This is stil…

I think GitHub is generally safe as long as you have an exit plan for when it's no longer the place you want to be. Know where you're moving your issues and actions if you decide you need to leave.

Re: SDL Moves to GitHub

#43

Post by filmgirlcw »

folkrav wrote: post #9
jmercouris wrote: post #4

Earlier quoted context omitted.

A much better UI. Git won because of the influence of the Linux kernel developers, that's all.

> A much better UI Curious as how it's "better". I have in all honestly only ever used git.

Tbh, I don't even know if it is true today. Circa 2008-2010, I think Mercurial was certainly better -- it was certainly better designed and easier for a newcomer to use.

I'm probably going to be wrong/off on some stuff, but this is what I remember from the old days:

* Mercurial had a better CLI by default -- it was closer to SVN, which made it easier to use, and it was designed so that you had one command that did one thing, whereas git was more flexible but you needed to remember a lot of option flags. * Mercurial had better early GUI client support (this changed, but early on, I know this was a draw for me as a Mac user) * I'm pretty sure Mercurial had better Windows support (I didn't use Windows so I can't speak to this, but I seem to remember this) * Better documentation

But git has evolved a lot over the last decade plus. Not only did GitHub really change the game by creating a more social layer on how to contribute/use git (and yes, I realize GitHub != git, but it definitely helped introduce a lot more people to git), it had features that really honed in on some of the pain points git had compared to Mercurial.

Although BitBucket was sort of positioned as a GitHub for Mercurial solution, it never achieved the organic/viral adoption of GitHub. And when Atlassian dropped hg support last year, it was pretty much confirmation that git "won."

Other than Facebook, I can't think of any major companies that use Mercurial or major projects that use hg.

I used to be sad about this, because I felt hg was better designed, but I came to terms with the reality a long time ago. It is what it is, and version control is often something that network effects define. Use whatever you want for your projects, but git won.

Re: SDL Moves to GitHub

#44

Post by jrochkind1 »

This is poignant for me, for reasons that have nothing to do with the technical merits of git vs mercurial, or github/Microsoft specifically as a company.

> It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable.

The bar has been raised for developer tools in 2021. The OP recognizes it, it's true.

The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially.

It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure.

(It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...)

And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in.

We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted.

But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to.

The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.

Re: SDL Moves to GitHub

#45

Post by einpoklum »

It seems to me people don't give enough thought to the possibility of hosting themselves elsewhere, and only "mirroring" onto GitHub for the presence effect.

GCC does this (edit: LLVM half-does-it, in that issues are handled elsewhere). So does MonetDB and I'm sure there are a million more examples.

Re: SDL Moves to GitHub

#46

Post by klodolph »

d1zzy wrote: post #12
talhah wrote: post #3

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?

Seems to be popular at Facebook.[1] Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things: - hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will au…

Mercurial is used at Facebook, but it is heavily customized and goes through Phabricator. Just like Google uses Piper, which is “like Perforce” and goes through Critique.

Re: SDL Moves to GitHub

#47

Post by jimbob45 »

livvelupp wrote: post #24
d1zzy wrote: post #12

Earlier quoted context omitted.

Seems to be popular at Facebook.[1] Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things: - hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will au…

What's the other options besides hg if it ain't git?

SVN still works well for our company.

Re: SDL Moves to GitHub

#48

Post by qbasic_forever »

mrpippy wrote: post #31
qbasic_forever wrote: post #10

Earlier quoted context omitted.

Git didn't exist until Linus Torvalds sat down and hacked it out in a few weeks during 2005. I remember using SDL back in '99 to play with game development on Windows 98. So the short answer is, git wasn't even an idea in its creators head when SDL was around and thriving. IMHO when you see a design decision that seems odd to you, it's a good opportunity to investigate the entire context around that design, rather th…

SDL didn't use Mercurial until 2010. They used Subversion from 2006-2010 [1], and CVS before that [2]. A project on its 4th version control system! [1]: http://forums.libsdl.org/viewtopic.php?t=6047 [2]: https://discourse.libsdl.org/t/sdl-in-subversion/13289

Again, I will restate what I said. Follow the context of the decisions (as you have already done) instead of demanding people explain it.

Re: SDL Moves to GitHub

#49

Post by klodolph »

RcouF1uZ4gsC wrote: post #8
talhah wrote: post #3

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?

One advantage of mercurial is that it is less tied to a specific file format like git is. It is much easier to make a mercurial backend for a system which actually stores the code in a different way (for example a distributed data store).

Isn’t this also possible with Git, at least for remotes? There are a number of different Git implementations besides the main one.

Re: SDL Moves to GitHub

#50

Post by 1_player »

PurpleFoxy wrote: post #16
rockooooo wrote: post #2

"So in moving it to GitHub, we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day. And I grew up during the heydey of the Free Software Foundation, so I know this is a trap, but I’m tired and don’t have the energy to be a server admin for something that’s held together with scotch tape and prayers when I’m really supposed to be writing OpenGL code." This…

Wonder why they did not pick GitLab since it is significantly better for FOSS ideals and has the same niceness of GitHub

> has the same niceness of GitHub

Debatable. As a previous paid customer, I have never been a fan of GitLab, I've always found it slow, buggy and of confusing design language. YMMV.

Post reply on HN