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.
Git is too hard
511–520 of 821 posts
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
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
#513Earlier 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…
Re: Git is too hard
#514I 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…
Re: Git is too hard
#515No 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…
Re: Git is too hard
#516The 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
#517Re: Git is too hard
#518Earlier 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…
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
#519Earlier 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.
Re: Git is too hard
#520I'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.
IMO nothing remotely like version control nor anything that requires a command line is going to click for someone in a non-technical field.