Git for Computer Scientists (2010)(eagain.net) |
Git for Computer Scientists (2010)(eagain.net) |
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
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)
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.
It could be a typo, or trying something new, or forgetting/misunderstanding the intent of some counterintuitive command, or maybe cleaning up an existing problem. All those things can easily put someone in a deep rabbit hole of inside git book or, worse, google search.
Naturally things go wrong occasionally, but garbage collection is not run often. You only need to know the SHA-1 and you can fetch "lost" commits again.
Old SHA-1s can be found in reflog. We also have all pushes automatically announced all in chat, so you can look up previously pushed SHA-1s in chat history (we use gitlab and zulip and those support it out of the box).
Of course you still need a mental model how git history (including history rewriting) works, othwerwise you cannot understand what exactly went wrong. And without knowing what went wrong fixing it gets awkward trial and error, which unfortunately many less experienced git users seem to do.
I find git easy to work with too though, as long as everyone sticks to a well-defined workflow and doesn’t do anything weird.
Removing from developer machines is a separate issue and requires you to be able to coordinate your Devs.
If you meant that it's not simple to work out from scratch what you should do without lots of reading and trial and error...that kinda goes for a lot of tools, no?
Technically, the issue was actually pushing that commit to the remote repository.
I think the best advise one can give people when using it is to to run:
git log -p origin/master..HEAD
See THIS is the problem. Ugly, inconsistent, clumsy use of the english language, and confusing.
This will go on my git sheet, with a comment as to what it actually does because I don't have the time to actually unpack that from first principles. I've got better things to do than become an expert on needlessly complicated software.
It's a command line interface, not plain English. What's ugly and inconsistent about the git log command as was quoted in your reply?
> I've got better things to do than become an expert on needlessly complicated software.
As a software developer, I have to read through a lot of documentation to be able to use programming languages, SQL, data stores, unix utils, etc. I don't see why it would be any different for a VCS.
I think the actual issue is that people aren't willing to read through the documentation to understand what a command does and what options are available.
As for the command itself, the -p switch shows the diff associated with each commit shown with the git-log command. origin/master represents the upstream tracking branch of the master branch (most likely the base branch that the person is working on). .. represents a range operator and HEAD repesents the commit that's the latest commit on the branch on the local machine.
Probably has to be done outside git, though. Maybe one of the corporate virus scanners will let you definite a local signature.
EDIT: Sorry, my bad. I misread.
SQL is not only much more intuitive than git, it gives me amazing leverage to deliver value to clients. By comparison, git wastes my time. There's zero or minimal competitive advantage to using it over any other VCS.