681

GOD DAMMIT STEVEN! NOT AGAIN! (lemmy.world)

submitted 7 months ago by Maven@lemmy.world to c/programmer_humor@programming.dev

72 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] masterspace@lemmy.ca 1 points 7 months ago* (last edited 7 months ago)

It’s because git is a complex tool to solve complex problems. If you’re one hacker working alone, RCS will do an acceptable job. As soon as you add a second hacker, things change and RCS will quickly show its limitations. FOSS version control went through CVS and SVN before finally arriving at git, and there are good reasons we made each of those transitions. For that matter, CVS and SVN had plenty of arcane stuff to fix weird scenarios, too, and in my subjective experience, git doesn’t pile on appreciably more.

Yes it is a complex tool that can solve complex problems, but me as a typical developer, I am not doing anything complex with it, and the CLI surface area that's exposed to me is by and large nonsense and does not meet me where I'm at or with the commands or naming I would expect.

I mean NPM is also a complex tool, but the CLI surface area of NPM is "npm install".

[-] zalgotext@sh.itjust.works 6 points 7 months ago

I am not doing anything complex with it

So basic, well documented, easily understandable commands like git add, git commit, git push, git branch, and git checkout should have you covered.

the CLI surface area that's exposed to me is by and large nonsense and does not meet me where I'm at

What an interesting way to say "git has steep learning curve". Which is true, git takes time to learn and even more to master. You can get there solely by reading the man pages and online docs though, which isn't something a lot of other complex tools can say (looking at you kubernetes).

Also I don't know if a package manager really compares in complexity to git, which is not just a version control tool, it's also a thin interface for manipulating a directed acyclic graph.

[-] masterspace@lemmy.ca 1 points 7 months ago* (last edited 7 months ago)

So basic, well documented, easily understandable commands like git add, git commit, git push, git branch, and git checkout should have you covered.

You mean: git add -A, git commit -m "xxx", git push or git push -u origin --set-upstream, etc. etc. etc. I get that there's probably a reason for it's complexity, but it doesn't change the fact that it doesn't just have a steep learning curve, it's flat out remarkably user unfriendly sometimes.

[-] zalgotext@sh.itjust.works 4 points 7 months ago

git add with no arguments outputs a message telling you to specify a path.

git commit with no arguments drops you into a text editor with instructions on how to write a commit message.

git push with no arguments will literally print the git push --set-upstream command you need to run if your branch has no upstream.

Again, I recognize that git has a steep learning curve, but you chose just about the worst possible examples to try and prove that point lol.

[-] masterspace@lemmy.ca 1 points 7 months ago* (last edited 7 months ago)

git add with no arguments outputs a message telling you to specify a path.

Yes, but a more sensible default would be -A since that is how most developers use it most of the time.

git commit with no arguments drops you into a text editor with instructions on how to write a commit message.

Git commit with no arguments drops you into vim, less a text editor and more a cruel joke of figuring out how to exit it.

Again, I recognize that git has a steep learning curve, but you chose just about the worst possible examples to try and prove that point lol.

Git has a steep learning curve not because it's necessary but because it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

It is great software and obviously better than most other version control systems, but it still has asinine defaults and it's cli surface is over complicated. When I worked at a MAANG company and had to learn their proprietary version control system my first thought was "this is dumb, why wouldn't you just use git like everyone else", then I went back to Git and realized how much easier and more sensible their system was.

[-] zalgotext@sh.itjust.works 1 points 6 months ago

a more sensible default would be -A

No it wouldn't. You'd have git beginners committing IDE configs and secrets left and right if -A was the default behavior.

vim, less a text editor and more a cruel joke of figuring out how to exit it.

Esc, :, q. Sure it's a funny internet meme to say vim is impossible to quit out of, but any self-respecting software developer should know how, and if you don't, you have google. If you think this is hard, no wonder you struggle with git.

it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

Just because you don't like the defaults doesn't mean they don't make sense. It just means you don't understand the (very good) reasons those defaults were chosen.

Git has a steep learning curve not because it’s necessary but because it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

Git's authors were the first users. The team that started the linux kernel project created it and used it because no other version control tool in existence at that time suited their needs. The subtle implication that you, as a user of git, know better than the authors, who were the original users, is laughable.

[-] masterspace@lemmy.ca 0 points 6 months ago* (last edited 6 months ago)

No it wouldn't. You'd have git beginners committing IDE configs and secrets left and right if -A was the default behavior.

No, you wouldn't because no one is a git beginner, they're a software developer beginner who need to use git. In that scenario, you are almost always using repos that are created by someone else or by some framework with precreated git ignores.

You know what else it could do? Say "hey, youve said add with no files selected, press enter to add all changed files"

Esc, :, q. Sure it's a funny internet meme to say vim is impossible to quit out of, but any self-respecting software developer should know how, and if you don't, you have google. If you think this is hard, no wonder you struggle with git.

Dumping people into an archaic cli program that doesn't follow the universal conventions for exiting a cli program, all for the the goal of entering 150 characters of text that can be captured through the CLI with one prompt, is bad CLI design.

There is no reason to ever dump the user to an external editor unless they specifically request it, yet git does, knowing full well that that means VIM in many cases.

And no, a self respecting software developer wouldn't tolerate standards breaking, user unfriendly software and would change their default away from VIM.

Git's authors were the first users. The team that started the linux kernel project created it and used it because no other version control tool in existence at that time suited their needs. The subtle implication that you, as a user of git, know better than the authors, who were the original users, is laughable.

Lmao, the idea that we should hero worship every decision Linus Torvalds ever made is the only thing laughable here.