Live data from Hacker News

Git is too hard

changelog.com

171–180 of 821 posts

Re: Git is too hard

#171
I'm an academic. I use git for some projects. I would love something between git and Dropbox: Dropbox's ease of use and automation, but git's ability to add branches. I've struggled to persuade co-authors to use git. There is too much to learn.

Re: Git is too hard

#172
post #144
post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…

I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits?

All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes.

Sure, if you’re really disciplined you can produce small commits without staging, by committing as you go along, but you’re breaking flow every time you commit in this style.

I say all this because I would love a CLI that has half-way sane handling of (e.g.) restoring staged, deleted files; doesn’t conflate restoring files with switching branches; has consistency of flags between commands (such as commit vs stash message); etc., etc. I should try gitless ;)

Re: Git is too hard

#173
post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

It's years ago, but I recall as a rookie I found mercurial way more approachable and easy to grok. Still distributed and a similar model to git, but considerably more approachable CLI interface and manpages.

Re: Git is too hard

#174
post #148

Earlier quoted context omitted.

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout

So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for t…

You can't push a rebased branch without`--force`, and the server can be configured to disallow it entirely. This is exactly how it should be: I want to be able to rebase my by public branches but not the public branch.

Re: Git is too hard

#175
post #144
post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…

Maybe what we really need is not a new VCS, just a new CLI frontend for git.

Re: Git is too hard

#176
post #171

I'm an academic. I use git for some projects. I would love something between git and Dropbox: Dropbox's ease of use and automation, but git's ability to add branches. I've struggled to persuade co-authors to use git. There is too much to learn.

Yeah, I learned git because my supervisor was using it on a research project. I made a few mistakes but he helped me mop them up and correct them. Now I use it for everything - I honestly dont see how I could go back. I cringe now everytime I see someone with multiple copies of a file with version numbers on it. I too have tried educating colleagues on it but it doesn't stick unless you really need to use it + intertia of having an established working method.

Re: Git is too hard

#177
post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

Git's hard when you see googling for syntax as a failure in the system. If you see getting SO answers as working as designed, it's quite easy. The main learning curve is just the idea of everything being branched, which is an increasingly common concept in many spaces.

Re: Git is too hard

#178

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217

What Hilbert space would that be?

I am not sure, but I think it's a Joke Hilbert space

Re: Git is too hard

#179

Earlier quoted context omitted.

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout

I think `git checkout` definitely needs to be there. Also `git reset` in case you make a mistake while `git add`ing

I think the most common usage of that - switching branches - could be replaced with `git switch` now. That leaves `git checkout` in the set of more advanced operations for more niche use cases.

Same goes I think for `git restore` over `git reset`.

Re: Git is too hard

#180

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…

This is a disgusting, harmful take. You should really step back and rethink your assumptions here. Git is a tool that’s meant to make things easier. It’s complex enough, though, that it’s a stumbling block for a lot of folks for a workflow that really shouldn’t be so complicated.

If you intuitively grok how git works, that’s great. I’m going to guess you probably don’t really use it in any challenging or new situations and are just comfortable with your particular workflow. But maybe you do have that mastery level over this one tool in your code management system.

But guess what, other folks, true genius folks, either can’t or don’t have the mental bandwidth to learn every nook and cranny of this tool. If you don’t recognize that, you are willfully dismissing a lot of really smart people because their brains don’t work the same way yours does. But when you do that you are weakening yourself and your own capabilities.

So step back and re-assess your take here. It’s wrong, and it’s toxic to your own outlook as well as those around you.

Post reply on HN