I'm happy I didn't have to scroll too far to see this.
Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.
I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.
The same can be said about regexes.
Regexes and git are probably the two tools which I have benefitted the most from learning compared to how little time I've spend on learning them - and I wouldn't even consider myself an expert on either.
> it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.
Yes, that's what people mean when they say that git is hard. Instead of presenting you with an interface expressed in terms of the domain you intend to work in, whose commands represent the tasks you intend to perform, git dumps its guts all over the place and requires each user to re-implement the interface between "what you want to do" and "how git is built" inside their own brains instead. Once you have written git's missing user interface in your brain, you are fine; but that's a lot of work which is not necessary with other version-control systems.
>I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.
For example: you have bazilion ways to achieve the same thing, all of them having its own quirks/advantages?
It is just poorly designed, that's it, lol.
I like to joke that if somebody else invented Git, then it'd be 10% less powerful, but 10 times more user-friendly
But any software evolves over time so if it had fewer ways of doing things in the past, it would very likely eventually pick them up because people have use cases for the advanced features.
It's like complaining about languages ("English is hard to spell and doesn't have consistent pronunciation" etc.), they're constantly changing and that kind of thing is going to happen eventually...
Git is a technology that was invented to simplify things that ended up getting so complex over time that an entire industry started up around it to try to make it simple again.
Actually, no. Git was a technology invented specifically to enable Linux kernel development. It hasn't become any more complex since its inception. The problem is most people aren't doing kernel development and have absolutely no idea what a distributed version control system is, yet they use git, a distributed version control system. I have no idea why we use it, to be honest, but I'm very glad that we do because the previous options were crap. Perhaps Mercurial is better, but git is good enough.
We were using svn before Git and easy cloning (and then PRs) has solved a LOT of problems. There are definitely still some things left to improve, though.
"hard"? it is not hard, it is just poorly designed, the API (commands) are really terrible.
Think of it: one person who cares about UX decades ago could make git 10 times more sane for milions of devs.
I'm happy I didn't have to scroll too far to see this.
Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.
I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.
The same can be said about regexes.
Regexes and git are probably the two tools which I have benefitted the most from learning compared to how little time I've spend on learning them - and I wouldn't even consider myself an expert on either.
> it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.
Yes, that's what people mean when they say that git is hard. Instead of presenting you with an interface expressed in terms of the domain you intend to work in, whose commands represent the tasks you intend to perform, git dumps its guts all over the place and requires each user to re-implement the interface between "what you want to do" and "how git is built" inside their own brains instead. Once you have written git's missing user interface in your brain, you are fine; but that's a lot of work which is not necessary with other version-control systems.
>I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.
For example: you have bazilion ways to achieve the same thing, all of them having its own quirks/advantages?
It is just poorly designed, that's it, lol.
I like to joke that if somebody else invented Git, then it'd be 10% less powerful, but 10 times more user-friendly
But any software evolves over time so if it had fewer ways of doing things in the past, it would very likely eventually pick them up because people have use cases for the advanced features.
It's like complaining about languages ("English is hard to spell and doesn't have consistent pronunciation" etc.), they're constantly changing and that kind of thing is going to happen eventually...
Git is a technology that was invented to simplify things that ended up getting so complex over time that an entire industry started up around it to try to make it simple again.
See also: Docker. Probably lots of others.
Actually, no. Git was a technology invented specifically to enable Linux kernel development. It hasn't become any more complex since its inception. The problem is most people aren't doing kernel development and have absolutely no idea what a distributed version control system is, yet they use git, a distributed version control system. I have no idea why we use it, to be honest, but I'm very glad that we do because the previous options were crap. Perhaps Mercurial is better, but git is good enough.
We were using svn before Git and easy cloning (and then PRs) has solved a LOT of problems. There are definitely still some things left to improve, though.