A Hacker’s Guide to Git • Hacker News Board

Re: A Hacker’s Guide to Git

#101

Post by SoftwareMaven » Tue, May 27, 2014, 8:27 PM UTC

Crito wrote: post #91

lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me. The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.

This is true, if you actually care. Many people don't want to have to know the inner guts of how every tool they use works and just want to get their work done. It's unfortunate that git seems to (almost) require it (most likely because of its inconsistent UI (which has gotten better)).

Re: A Hacker’s Guide to Git

#102

Post by wmt » Tue, May 27, 2014, 8:38 PM UTC

"Once you start talking about branching, merging, rebasing, multiple remotes, remote-tracking branches, detached HEAD states… Git becomes less of an easily-understood tool and more of a feared deity. Anybody who talks about no-fast-forward merges is regarded with quiet superstition, and even veteran hackers would rather stay away from rebasing “just to be safe”."

"That’s why trying to understand Git in this way is wrong. Git doesn’t work like Subversion at all. Which is pretty confusing, right?"

These kind of assumptions of the reader can be quite off-putting. If you don't relate to assertions like this in the introduction, you start to wonder if the rest of the article is based on these assumptions.

I user SVN happily for years before moving to Git a number of years back, and the conceptual migration felt really smooth. It was just like SVN, but with some nice new native branching tools and features, like in SVN you were forced to merge trunk changes to feature branches, whereas in Git you also have the option to "move" i.e. rebase the branch onto a newer commit.

The rest of the article was very good!

Re: A Hacker’s Guide to Git

#103

Post by wldlyinaccurate » Tue, May 27, 2014, 9:15 PM UTC

tieTYT wrote: post #99

I've got the right level of understanding of Git to grok this article. I really liked how you talked about cherry picking before you talked about rebaseing. I'd like to request you include a section on why/when you need the rebase --onto argument.

I think the cherry-picking example borders on being too long and complex, but I'm hoping it still gives that "aha" moment when you realise that you've just done a rebase the hard way.

Great suggestion about --onto, thanks! That is a tough one to explain in a concise way, but I'll give it my best shot.

Re: A Hacker’s Guide to Git

#104

Post by SoftwareMaven » Tue, May 27, 2014, 9:29 PM UTC

seren wrote: post #39

Quick question for people using git daily : do you push the features branches to a central repo or you simpy merge with --no-ff on a common dev branch ? (There is no necessarily a right answer, but I'd like to know what is more usual)

Feature branches are pushed to remote, where code reviews can take place. Once the code is reviewed and approved, the submitter rebases it onto master. We run a batched continuous integration, so once it's on master, it is expected it could be pushed into production at any time (batched because somebody has to do the push manually, usually after merging the code).

Re: A Hacker’s Guide to Git

#105

Post by dahart » Tue, May 27, 2014, 10:23 PM UTC

edanm wrote: post #93

dahart wrote: post #87

Earlier quoted context omitted.

Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI. But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were. And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labo…

"And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology." I heavily disagree with this. When I started heavy use of git branches, being able to actually visualize what a branch is (e.g. just a pointed, as the art…

I don't disagree with you. ;)

Its a fair point that visualizing branches makes a big difference to people learning git. One reason that all git intro articles have these A->B->C diagrams.

FYI, the git CLI can give you branch visuals, e.g., 'git log --graph'. I was honestly thinking beyond basic branching when I wrote the above, but its worth remembering that the basics matter, and I also wouldn't even disagree with someone who claimed a GUI branch graph is easier to look at than a CLI branch graph, even though there may be no informational difference.

Still, I think the larger points I was trying to make stand:

- There is no git GUI that can replace the git CLI. There are many GUIs that give you pieces of git's workflow, but none complete enough to be a true one-stop-git-shop -- especially when it comes to more advanced workflows & repo administration.

- Git was not designed for a GUI, it was designed for a command line, and it shows in many ways. The CLI is the only place you can use all of git's power and understand all of git's features. It's also, as wildlyinaccurate was trying to explain, the lowest common denominator interface, hence the easiest to start basic explanations with. All people who have git have a CLI interface. Written with any GUI in mind, and a git tutorial immediately loses the majority of its potential audience.

Re: A Hacker’s Guide to Git

#106

Post by Crito » Tue, May 27, 2014, 10:23 PM UTC

SoftwareMaven wrote: post #101

Crito wrote: post #91

Earlier quoted context omitted.

Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me. The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.

This is true, if you actually care. Many people don't want to have to know the inner guts of how every tool they use works and just want to get their work done. It's unfortunate that git seems to (almost) require it (most likely because of its inconsistent UI (which has gotten better)).

The way I see it, the CLI stuff is a distraction, when you "want to learn git", what you really want to do is understand how a DAG can be used for version control. Git is the idea. The standard/stock CLI is just one of many imperfect realizations of the idea that is git. Getting the handle of that particular realization of git is an unfortunate distraction that is needlessly weird in some cases.

Think of it like the difference between learning how an engine works, and learning how [some particular engine, in some particular car] works. The first is pretty simple and illuminating. The second has lots of annoying details and imperfections. If you want to work with cars, you learn the former first.

Re: A Hacker’s Guide to Git

#107

Post by todd8 » Tue, May 27, 2014, 11:01 PM UTC

Crito wrote: post #91

lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me. The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.

Your second paragraph hits the nail on the head. It's the Feynman Technique for learning.

See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...

Re: A Hacker’s Guide to Git

#108

Post by voltagex_ » Wed, May 28, 2014, 12:12 AM UTC

lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

Definitely interested in seeing your notes, even though there are a staggering number of git tutorials around.

Re: A Hacker’s Guide to Git

#109

Post by avinash240 » Wed, May 28, 2014, 1:38 AM UTC

My biggest issue with git is it's CLI design. It's absolutely inconsistent. I don't believe the internals are an issue. If you really want to make git better, destroy the CLI and build a new one. Instead there are a million of these tutorials(the fact that there are a million tutorials should already hint at something being wrong), talking about internals.

Re: A Hacker’s Guide to Git

#110

Post by ab » Wed, May 28, 2014, 3:57 AM UTC

lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

+1

I'd love to see your notes.

I found that when I was learning git there were two concepts that were crucial: understanding the staging area, and understanding the very basics of the DAG (not talking about tree objects, only spending just enough time to learn how to merge and rebase).

I have to say I was a little disappointed this tutorial didn't even mention the word staging, since it's pretty important to being able to use the interface.