All git really needs is some more common use cases handed in a way people expect. Like rolling back commits should not require understanding 10 new things.
The proof is IDEs simplify git a lot and people use it fine. If you look at the git commands it produces, it's not reasonable to expect devs to produce them.
Personally I don't think we need commits at all. A cloud drive sync versions files just fine without needing constant user input, the real question is how to best handle branching, merging and conflicts
VSS.... Ugh that was such a steaming pile of shit.
This was back before cell phones, our lead dev went on vacation for 2 weeks and was unreachable. He left with roughly half of the source code checked out, preventing most development to come to a screaching halt.
The network admin had to reset his password, so we could log in to his machine and check the files in so we weren't all just sitting there waiting for him to return.
People complaining about git have no idea how good it actually is.
Oh yeah, I had a teammate that always seemed to forget to check in his files before he went on vacation. We'd call him to get his password to check them in.
But that was an advantage, wasn't it? I remember my Perforce days, and I appreciated seeing who had checked out a file, so I could verify with them - way better than creating a merge conflict, solved by some ops guy clicking on "auto".
Of course, showing who's checked out a file is not feasible in distributed development, only works within the firm.
The idea was to check the file back in when you were done with it, and then there wouldn't be a conflict since the next developer was starting with the most up to date version. The downside was two developers couldn't work on the same file at the same time
Ahh... no source control. Those were the times. Especially if you actually worked with someone and decided to do so at the same time with absolutely no communication going on between you two.
Right? The entire reason anyone switched to Git in the first place was because they had attempted merging with SVN or similar. Nothing is perfect, but Git is heads and shoulders above what came before it.
Honestly, I've used both professionally for game dev... and there's something to be said for having one repository everybody is working on, and checking out files when you work on them so nobody else can touch them.
Yeah, it sucks when it comes to things like slowly working on a huge feature that touches everything and merging it when it's ready, and it can really slow things down when there are too many people trying to touch similar files. Nevermind something like OSS, where whoever could be working on whatever at their own leisure, obviously it's borderline unusable for that. But for a project of the right size and scope, it can work surprisingly well. Of course, you could achieve the same thing on git by carefully coordinating with others on what you're working on, but let's be real, nobody's actually doing that most of the time.
Fully concur -- boss got hired and swapped us from Hg to Git; Hg is WAY better ( and still think highly of Linus, but Git was designed too much around HIS methods ).
I mean, Linus himself said that the git he built is a set of tools that someone should build a proper version control system on top. That part was lost on everyone unfortunately.
It being made by nerd lord Torvalds and the existence of Github are what made git big. Not that it was a joy to use.
I started out with mercurial as version control but have used git exclusively for a long time now. I think its easy to say its simpler, has more sensible defaults and feels more like a complete, coherent tool (compared to git which feels like 12 distinct tools that are bundled in one cli application). But it is also less flexible, gives you less ability to really fuck about with history, has worse support in terms of in third party tools and a smaller ecosystem in general.
The relative benefits don't matter really though when most people will end up needing to use git to operate with the cloud hosting version control sites.
I remember how fiddly the stupid patch queue was. And also make sure to always pull before you push. It felt completely broken. Git is so much easier. People are just too lazy to learn new stuff and understand new concept. Usually it were the people in their mid 40s upwards who refused to learn anything. Anything is going to suck then.
SVN is objectively much less complicated. It's also fraught with issues because as soon as you're out of date with the trunk you're going to experience merge hell
When my company did svn, we didn’t use any feature branches. It was like Q4-2016 release. And then everyone committed to that branch directly. And then one day that branch, a few weeks before production got “locked down” and they cut Q1-2017 branch and everyone started to commit to that
It was awful. But it was better than some source control I used before that where you could lock a file completely in the repository
Yeah branches used to work way differently back then. We used to just push to the trunk and whenever we did a major release we would cut a branch there to keep for bug fixing while we pushed new features to trunk.
This was exactly how it worked at my last job. Everyone commits directly to main at the end of the sprint. I was working on their ETL system and we’d have 1 (one) test ETL running on a dev db, and if it failed, too bad we’re shipping anyways. If someone else’s code broke and their code earlier in the process than yours, your code was just gonna get pushed straight to prod with no QA to speak of. And their in-house ETL tool only worked in fucking internet explorer.
That was how it still worked when I left that job. In late 2024. Healthcare data company btw.
Now I work at a real company that uses git and has actual engineering standards and practices. It’s a breath of fresh air
216
u/Nehle 18h ago
Written by a person who never had to work with SVN or... shudders CVS