Live data from Hacker News

Git is too hard

changelog.com

511–520 of 821 posts

Re: Git is too hard

#511
I've trained multiple teams to use Git (which means I've been their on-call tech support) and I agree the learning curve is tough. However I argue that the value added is so high that the initial curve is worthwhile. I usually start by explaining that Git was made by kernel coders who like low level access, so git hides nothing from you and provides a very generic solution that works for almost everyones use case. GUI tools will cover you in simplest of scenarios, but it's a matter of time until you need to do something marginally complex and are left hanging out to dry. I advise not using them at all because the details they hide are the only thing that will help you understand the advanced features.

Once you're over the hump the system is very intuitive. I liken it to awk or sed which beginners often find incomprehensible, until they understand what the tools do at which point they become simple. There's a lot of good resources out there and StackOverflow has almost every question imaginable already asked and answered.

Re: Git is too hard

#512

“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

This is funny but I think it strikes at a real truth: what Git is trying to do is legitimately difficult. I can see where the author of the article is coming from and I agree that Git has a lot of commands and it's hard to pull it all together, especially if you are new. And I agree that these commands could be better organized and presented and I think that's something the project is actively trying to address.

But isn't the core idea of Git, everyone has their own repository and they share branches, kind of complicated and tricky? In my experience the developers I see having problems with Git are having trouble with the hard stuff, not the easy bits like committing and pushing a change.

Re: Git is too hard

#513

Earlier quoted context omitted.

Based on my experience - most teams will get by with ivanhoe's list. You additional items are definitely helpful - but the typical team member's workflow won't cross those bridges. Team leads perhaps. There's definitely levels of proficiency, but for a junior or even mid-level dev doing feature work, I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…

Could you not perhaps git fetch && git rebase origin/master (for instance, to pull remote changes into a local development branch)?

Re: Git is too hard

#514
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 feel the same way, I understand git pretty well but cannot for the life of me use the CLI. Fortunatly there are some pretty good GUI around, I personally use GitExtensions and find it suits my brain nicely. Its windows only though, not a problem for me since my work forces me to use Windows and I don't code at home but surely they are nice git GUI for Linux no ?

Re: Git is too hard

#515

No it's not. If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UIX" and "everything has to be 'easy'" the more we stray from incredibly powerful, immediately available CLI tooling. I know of too many highly-paid people who literally refuse to learn the CLI `git` or `docker` and limit themselves/skillsets by doing everything…

It's probably laziness. Is that such a bad thing though? I think its ok to expect tooling to be easy so we can spend our times on actually writing code. To me it's the same thing as expecting auto completion and line by line debugging from our IDEs.

Re: Git is too hard

#516
Since my experience with Git is much less (too much solo work, so you don't get exposed to the same scenarios as team developers do), I'm now having to handle new situations in my Git use.

The biggest problem I face is the conflicting information of how to do a certain thing. The other biggest problem is that my need at one moment may be similar by slightly different to a situation/question posed on StackOverflow, and so I'm left to guess if I can take the answers and work from those... or if I will end up in a worse or weird situation by following them.

It's very difficult to even discuss situations in Git, because the smallest details can be a deciding factor in choosing what next step to take. It reminds me of analog and digital electronics... sometimes you must be very precise and know exactly what you're doing, and sometimes you can just approximate. Knowing when to do one or the other takes lots of experience.

Re: Git is too hard

#518

Earlier quoted context omitted.

> But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". Simple needs have simple answers. git add . git commit -am '2020-11-17' Sure, you can ask "why are there two commands?", but this is not so much an issue of cognitive burden as of typing burden. If you only want one thing, you only have to know how to do one thing. If you don't want to know why the…

When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it. This is the mental model 99% of newbies will have for something that basically pledges to save and sync each version of your files. Deviating from the user's mental model will create roadbumps and should not be done without a very strong rationale. Especially not for a…

When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it

So? When you're saving a file, you're also overwriting its entire contents. Good luck reverting back to the file before you saved it.

There is no automatic model for "this change is worth tracking" and "this change is not important enough to annotate". That's the model that git is enabling, and it has nothing to do with the "save" button in an editor. If anything, it has more to do with the "track changes" feature in Word, but more powerful because it allows you to group multiple edits in the same change.

Re: Git is too hard

#519

Earlier quoted context omitted.

Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only…

We deal with this via code review. Anything with such files is going to get instantly rejected. And people soon learn not to do it.

So with every new hire, you have burden the reviewer again? Wouldn't it be better to make the default so that Visual Studio burdens the primary developer, instead of the reviewer?

Re: Git is too hard

#520

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

What do you recommend in these cases? People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". My mind goes straight to VCS, but git is too hard to get them quickly up and running. I tried SVN one time, which is a little simpler, but still didn't catch on with the person I was showing it to.

> People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files".

IMO nothing remotely like version control nor anything that requires a command line is going to click for someone in a non-technical field.

Post reply on HN