Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to teach Git

rachelcarmena.github.io

Post reply on HN
Print view View original

131–140 of 273 posts

Re: How to teach Git

#131

Post by Fellshard »

99052882514569 wrote: post #120
Ajedi32 wrote: post #47

Earlier quoted context omitted.

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

I just use a GUI for that. I don't like using applications like Sourcetree for any actions, but they really are superior for visualisation of the commit tree, diffs between non-adjacent commits or between branches, etc.

I'd recommend Git Extensions, still, as a good compromise between porcelain and plumbing. The most useful commands are all at your fingertips, with deeper ones available if necessary. Visualization is best I've seen - clean graph display, easy to read, and _doesn't lie in complex cases like SourceTree does._

SourceTree tends to treat commits with multiple ancestry in a very weird way that has led to difficulty on multiple occasions, where people think changes 'went missing' because SourceTree decided the other ancestor wasn't important enough to show.

Re: How to teach Git

#132

Post by mixmastamyk »

dahart wrote: post #68
JediWing wrote: post #21

Earlier quoted context omitted.

So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…

You never amend commits or rebase locally before pushing? I rebase before pushing almost every time. Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes.

Never, and can never remember what rebase actually means.

At work I’ll hit the squash option on gitlabs merge request which moots all local machinations.

Re: How to teach Git

#133

Post by da_chicken »

allenu wrote: post #114

I gave a git talk at work recently and what I found works was teach the graph from the beginning. This includes a lot of diagrams of what the graph looks like as you commit and branch: - show what happens as you add commits to a branch - show that branches are just pointers to commits - show what creating new branches looks like, i.e. creating a new pointer - show what merging looks like (a new merge commit is added,…

Yeah, it was definitely a set of images [0] that made git click for me, but even those are not necessarily the best pictures to use.

Git's mental model is basically:

> Ok, what if we took our SVN repository and the first thing we did was check in an SVN repository to that. So now you check out the repository, and you get a complete local repository that you can do anything you want with!

> So Pull/Push are the terms we use for the check out and commit of your local repository to the remote repository, and then Checkout/Commit works from your local repository just like you're used to with SVN.

And the real magic is what they did by building a system on top of this model to let you merge changes all the way up while looking at the code like you'd expect you'd need to.

The problem is that git's toolchain still feels arcane to use, and it requires that you have good working knowledge of the underlying models. It's confusing enough that you can't function unless you have that because you don't know where you are or where you're going. It's a fantastic tool, but it's like driving a car with two steering wheels, two gear shifters, and six pedals. Then you say to yourself, "How do I get to the market, buy some milk, and come right home?" and your brain starts to melt a little bit.

You shouldn't need to know the nitty gritty of how git works internally just to get it to work right any more than you should need to know how a disk works in order use a file system, but over and over we keep seeing that knowing that is really the only way to use the tool correctly and that it takes quite awhile for people to get.

[0]: https://blog.osteele.com/2008/05/my-git-workflow/

Re: How to teach Git

#134

Post by da_chicken »

oblio wrote: post #80
Ajedi32 wrote: post #47

Earlier quoted context omitted.

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Git in many occasions (including when using git log) feels like the designer just threw their hands up and said: "F*ck this shit, make your own UI on top if you want to use this tool!" I don't think Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :( (To the people going: "Oh, it's Open Source!". Sure, so are Mercurial, Fossil, etc.)

It definitely feels like it was written by someone used to writing an ABI or library rather than a set of command line tools.

Certain tools are organized by what code goes together rather than by what user functions make sense to go together. It's part of what makes it confusing.

Re: How to teach Git

#135

Post by Walkman »

This is very good explanation, but only explains what happens with the files, nothing about the graph what is a git repository. This talk helped me tremendously to finally understand what's going on in git: https://www.youtube.com/watch?v=1ffBJ4sVUb4

It is one of the best talks about git for beginners with an unfortunate title :D

Also, this interactive visual tool helped me to understand branching: https://learngitbranching.js.org/

Re: How to teach Git

#136

Post by akulbe »

iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

This is so so fitting, and describe me to a "T" as well.

I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.

Re: How to teach Git

#137

Post by Animats »

From the article: "If you take care the commit history, consider the use of git pull --rebase. Instead of fetch + merge, it consists of fetch + rebase. Your local commits will be replayed and you won’t see the known diamond shape in commit history."

No, not how to teach Git.

Open source just can't do good user interfaces. The result is almost always a zillion features in search of an architecture.

Blender managed to almost dig itself out of that hole, but it took over a decade. Gimp is still down in the pit.

Re: How to teach Git

#138

Post by chousuke »

jejones3141 wrote: post #40
jstimpfle wrote: post #31

I found this very helpful: http://eagain.net/articles/git-for-computer-scientists/ . Git's data structures are well designed. Once you have internalized them, you will be better equipped to navigate through the jungle of command-line options. To understand the data structures interactively, use "git cat-file -p HEAD" and continue drilling down to an individual file in a subdirectory with "git cat-file -p OBJECTHASH "

I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamics. Why should it be necessary for git?

You don't need to understand git's internals; I for sure don't know how it does delta compression of pack files etc. to provide you with efficient storage of snapshots and whatever else it does.

However, what you do need to understand is the model that git uses, which is extremely simple.

Git provides you a way to store snapshots of data into an on-disk graph data structure* that you can sync to and from remote repositories. You also get refs to store symbolic references to the snapshots in the data structure, and you can sync those too.

That's pretty much my mental model of git in its entirety, and it allows me to merge, branch, rebase and perform all kinds of commit surgery with ease, because I can always tell what effect an operation is going to have on my data structure (and even if I'm wrong, I can't lose data)

I seriously can't see how it could get any simpler.

(*) a git repository can actually contain several separate graph data structures, but that's usually not what you want...

Re: How to teach Git

#139

Post by sephoric »

Animats wrote: post #137

From the article: "If you take care the commit history, consider the use of git pull --rebase. Instead of fetch + merge, it consists of fetch + rebase. Your local commits will be replayed and you won’t see the known diamond shape in commit history." No, not how to teach Git. Open source just can't do good user interfaces. The result is almost always a zillion features in search of an architecture. Blender managed to…

I was just running into this dichotomy this morning. To test my app Autumn on High Sierra, I had to install it in a VM, so I tried VirtualBox (open source) and Parallels Desktop Lite (in-app purchases). Not only did Parallels have a smoother, cleaner, more modern and easier GUI, VirtualBox just out-right doesn't work when trying to install High Sierra, and I had to find third-party instructions online just to bypass this bug. Plus it likes to crash right after shutting down the VM. I'm not really sure if there's some deeper philosophical reason behind this dichotomy, but I've seen it hold true for a lot of apps and their open source alternatives, and many people have said the same thing holds true about my app Autumn and open source alternatives like Hammerspoon and Mjolnir. As a rule, we really do seem to get what we pay for.

Re: How to teach Git

#140

Post by y4mi »

sephoric wrote: post #139
Animats wrote: post #137

From the article: "If you take care the commit history, consider the use of git pull --rebase. Instead of fetch + merge, it consists of fetch + rebase. Your local commits will be replayed and you won’t see the known diamond shape in commit history." No, not how to teach Git. Open source just can't do good user interfaces. The result is almost always a zillion features in search of an architecture. Blender managed to…

I was just running into this dichotomy this morning. To test my app Autumn on High Sierra, I had to install it in a VM, so I tried VirtualBox (open source) and Parallels Desktop Lite (in-app purchases). Not only did Parallels have a smoother, cleaner, more modern and easier GUI, VirtualBox just out-right doesn't work when trying to install High Sierra, and I had to find third-party instructions online just to bypass…

You're pinning THAT on opensource?

a) VirtualBox is an oracle product. That by itself should be telling.

b) High sierra is unsupported as a Guest OS in VirtualBox. You do know what that means, right?

c) You seriously complain about the darth of open source virtualization for an OS, which disallows virtualization on anything but apple hardware? ...really?

If you want good open source virtualization you'll want to use Qemu/KVM. Which obviously doesn't support any apple OS either, because they're not allowed to virtualize it. Take that up with Apple, not open source

Post reply on HN