I'm going to start a new project so i thought it was a good moment to try GitLab because the project would benefit from collaboration, SourceForge isn't good for that and I want to leave GitHub. But it was a mess. I mean I created an account and it drove me to create a group and a project but then to build a CD/CI stuff and everything did go crazy. I started to jump from a help document to another help document trying to understand what the hell it was talking about without success.
I just want to know how to create the trunk, branches and release directories/labels/whatever-GitLab-gibberish-call-it and commit/upload/whatever the files and make the day. Then next day learn how the merge thing works so I can add the fixes and improvements anybody send to me. But after an hour trying to figure out how to do that I decided to delete everything (including my user account so maybe I'll create it again and start as if I'm new).
Why is it so complex, so convoluted? Sure it it great for somebody but it is just a big red flag for a newcomer as I am (despite I was using SF for a long long time and GitHub for not so long time but long enough to learn one or two tricks).
That's all. Thanks for allowing me to rant a bit. Maybe later I'll try to find a GitLab for n00bs tutorial or something and try again
I'm right there with you. Git, and everything associated with it, gives me huge headaches. 0xDB and I used it when we were working on our first demo, and I've pretty much forgotten everything about it. Even then I was going through the motions, and not 100% sure I was doing the right thing at all opportunities.
I think things would benefit from a "simple" mode, where you open a project with a few files, and people can check out files and make changes, then merge, and the owner can roll back if stuff goes kaboom. Maybe I'm just being myopic, and all the extra baggage has to come around to get the other stuff. Who knows?
I also feel the same way about libraries. Everything now wants to target 4 or 5 operating systems, and god knows how many hardware platforms, and it can be a gigantic chore to build the lib if everything doesn't go off as it should. I give Raylib credit for being mostly painless, at least compared to many "big, monolithic" libraries I've tried out. The natural reaction, on the C side, has been the creation of a lot of "single header" libs, which is nothing short of fantastic.
Gitlab, GitHub, et. al., have an interesting learning curve since they each have different ideologies and norms about how things should work. I've used both -- not extensively though, just as a contributor rather than a project owner. I dislike how they all eventually end up becoming gamified. I really only learned "basic mode": put up a PR, do comments, get code merged.
Ultimately, I think if you learn the basics of git you should be able to get by without doing too much maintenance stuff on those collaboration sites. There is a ton of optional stuff that only really benefits larger projects with complete build/CI/CD pipelines, which you probably don't need for whatever you're currently spinning up.
I'm not sure any of this was helpful. I share some of your sentiment though so don't fret about venting. :]
Yeah GIT has a learning curve, but for what it's worth, once you _do_ get over the hump, you may find you can't go back.
GIT's forte is collaboration. It's also at its best when you aren't afraid to branch frequently. Once you have the basics all working, it's a best practice to be working entirely in branches instead of main/master. Got a bug to fix? Make a branch!
Seems like the assumption these days is that everything is a massively complex operation with a lot of people requiring significant investment. Even coding tools seem to be going this way. And one only has to glimpse at the influence google etc are having on c++ to see how pervasive this goes, the languages themselves are becoming incumbent on "bigness".
This is one reason I follow the handmade community, it's kind of a questioning and exploration of what it means to build things without this assumption of massive dependencies, huge complexity, and large teams (actual or virtual by building on complex ecosystems / libraries). A thoughtful consideration of when we should dive back down into the teetering stack of technology and simplify/reduce it again.
I don't think there's an easy answer here, but a philosophy where we at least question and occasionally find ways to simplify seems really important to avoid losing the accessibility a lone developer used to have to throw something crazy or interesting together. It's this fluidity and quickness that really supercharges innovation.
Agreed 100%. And this is why I've really been enjoying my off-and-on project this year of building a game framework (and games built with said framework) with as few dependencies as possible. Really just core SDL itself (none of the other extensions like SDL_image either). Really just embracing NIH syndrome to its fullest. Just building all my own stuff (poorly). It's been a very freeing experience.
Day job work these days is just constantly stringing together endless amounts of libraries and other dependencies and some weeks you just end up writing far more config files than you did code. I often feel like my title should be "Senior Config Engineer" or "Senior Gluer-Togetherer-Of-Things." And when I try to push back on stuff like this I receive confused stares and/or just get ignored. It is very tiring, very frustrating and is very much contributing to a rising hatred of this industry and what I do for a living.
I could rant endlessly on this topic. Maybe I will here in the near future, but I don't feel like it right now.
Suffice to say, I definitely feel y'alls pain on this too, and it saps my energy to work on anything and everything on a near daily basis.
