Maybe I "got gud" though and can no longer empathize with git beginners
The original git porcelain commands - git branch, git reset, git pull - are execrable. They’re filled with implementation details (index/cache vs staging), weird and suggestive syntax that seems like it should be extensible and widely applicable but isn’t (localbranch:remotebranch), and nuclear-powered self-destruct functionality hidden amongst playthings (git reset vs git reset —hard).
Most people most of the time will get by if they grab a decent git GUI, figure out the minimal set of operations they need, and just Google the rest when necessary.
My stupidest git mistake was when I was cleaning out a directory of bin and obj folders and included gits obj folder as well. And of course after crying in the corner for a bit I take a little time to look into git commands and I could have just run 'git clean'
The message "up to date with origin/master" is also misleading, because it doesn't check the remote itself.
gitk --all
Actually I work most of the day remotely in `screen` on my office machine. But in case of complicated/confusing/buggy history/branching I fetch for the repo so I can run gitk locally.
The hard part HAS ALWAYS BEEN is memorizing all those badly named and counterintuitive commands.
Give any Git newbie a decent GUI and a translation for Git terminology into sane terminology and they will have no problems.
I had no idea why it took my brain so long to wrap my head around it. Maybe it was blissful ignorance, never sitting down and making a mental model of it. Always looking for a tldr version of doing things. I don't know exactly at which point things clicked but it went from bewildering to just makes sense
Mmm no thanks! In any case there's no reason you can't use Git itself as a monorepo! You don't have to inflict SVN on people for that.
Very weird opinion.
The main problem I had with using git is it did not match the way we worked. Git assumes there is one person who is the gatekeeper, who decides what gets into the source, and who does some integration and testing. In research there usually is no one in charge of that, instead everyone is responsible for their own code, testing it, and integrating it. The git model was wrong for us, we never used pull requests at all, because there was no one person who understood everything well enough to approve them. Students don't have the experience or time to be the integrator, the profs don't even write code, and I had multiple other things that I had to do. So using git made a mess of what had been a simple process previously. Git was designed by Linus to make his life easier in managing changes to a kernel. It does not work well in other scenarios and should not be used in many circumstances. Yes, you can make it work, but at a cost.
1) It wants to be the only tool you need to bring with you if you and your fellow developers are going to be stuck on a desert island. It’s not only version control, but also an issue tracker, and more recently a chat app.
2) It preserves everything you commit to it. Whereas git lets you polish your commit history before pushing, fossil keeps everything. You can’t alter your local history. All your messy scratch work can’t be cleaned up. It’s visible forever.
That second point is what turns me off to it, so I’ve stuck with git for personal projects. When I push up my local code, I like to have a very clean history.
Apart from that, did you try it, and was it smooth?
But none of this matters, as git/github/gitlab is today the industry standard, or even the category killer for version control. You will have to deal with it in one capacity or another. So my advice is to deal with git, learn at least up to medium level. As industry standards go, things could be a lot worse than git.
My goal right now is to develop a better mental model of git than what I have right now. If anyone has recommendations for resources, please let me know!
Go through every lesson, understand it, and find yourself more knowledgeable about git usage than 95% of developers.
I look forward to sharing this with others on my team.
Git for Computer Scientists - https://news.ycombinator.com/item?id=3146466 - Oct 2011 (15 comments)
Git for Computer Scientists - https://news.ycombinator.com/item?id=1485612 - July 2010 (17 comments)
Yes I know what a directed acyclic graph is. No I don't know what 'checkout' will actually do this time when I run the command.
It's been 10 years. It's still confusing people. There's still article after article, book after book written on a tool that should be getting out of a programmers way.
Let's try something else.
[1] https://lwn.net/Articles/811068
[2] https://lore.kernel.org/lkml/xmqqy2k2t77l.fsf@gitster.c.goog...
> Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
* Isaac Wolkerstorfer, https://twitter.com/agnoster/status/44636629423497217
For example: “two weeks ago an intern accidentally committed a file containing IP we’re not allowed to use, we need to erase it from the repository and all developer machines.”
Have fun with that one!
EDIT: I mean, try to figure this out from the official Git documentation (https://git-scm.com/docs). No, Stack Overflow and Github are not the official Git documentation. Believe it or not, the idea that "Git is hard to use" predates Stack Overflow.
If you mean that literally, this joke is referencing another joke meme in the functional programming community, explained here: https://blog.merovius.de/2018/01/08/monads-are-just-monoids....
If you mean, you don't get why people joke about Git being hard, it probably isn't for most professional programmers already accustomed to some kind of source control, just perhaps to anyone new to it.
I think that people think they are confident about Git in 'a few weeks' are basically have a lack of self-awareness. They 'don't know what they don't know'.
I've seen countless times, developers huddled around someone else's computer, trying to figure out what went wrong.
I saw a git animation/visualisation tool once that animated operations, and I saw things happening I had never seen before, basically a lot of 'loose end' things that I didn't even know existed.
I also wonder if that has something to do with the fact that such things are maybe not suited to 'command line' and are inherently structured.
But I think the trouble with git is that it is very flexible, there are many ways to do things (ex: merge vs rebase) and the command line interface is not particularly intuitive. I messed up with git much more than I messed up with mercurial, but git also makes it easier to fix the mess.
Step 1.It is explained that Git is a simple program, and that the underlined idea can be understood easily, it is only that other materials have done a bad job about it.
Step 2. Tell the reader a blob is just the byte object containing the information you are source-controlling. "See how easy it is?"
Step 3. Invent their own nomenclature/diagrams/metaphors for all the other concepts, totally muddling the waters.
Step 4. Become one of the resources criticized on Step 1.
My other personal issue is the complete opposite of the "going way too deep into details" teaching resources: showing clone/commit/push/pull and calling it a day. This leads to resources like ohshitgit.com as things will eventually break when people use commands without understanding what is happening.
When doing our workshops, we go through the basics: what is a commit, what is a branch, what is HEAD, what do commands like checkout/reset/rebase do on graph level. This approach demistifies Git without going into internals. It also takes away the fear of "advanced" topics (like "rewriting" history)