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

Visualizing Git Concepts with D3.js

wei-wang.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Visualizing Git Concepts with D3.js

#33

Post by stormbrew »

wudf wrote: post #22

New to git as well as programming in general. This site has helped me somewhat, but I'm still confused about some basic concepts. Aren't the arrows all facing the wrong way? What happens to a commit after 'git reset' abandons it; can the commit be accessed ever again? What's the difference between reset and revert? How can merge and rebase be trusted? What are the best practices for how many branches a project should…

Something no one has mentioned but I think is important is that reset is best not thought of in relation to revert but in relation to checkout. Each of these commands operates on very different things, but they all seem to have similar purposes at a very superficial level [1].

- Checkout manages HEAD. When you use checkout, HEAD is changed to point to the branch, commit, tag, or whatever you've told it to and the working copy is altered to match that ref.

- Reset manages what commit a branch points to (though, see [1] again for the disclaimer). Several of my sibling posts here talk about it altering history but I think this is not really a correct way to look at it. Branches, in git at least, are not really 'history'. They are dumbass pointers and they move around a lot. This is not an alteration of history most of the time.

- Revert creates a commit, so is actually not really like the above two commands at all. It's just an automatic way to create a commit that undoes an earlier commit (which can even be a merge commit, btw).

The more destructive version of revert is actually rebase, which can truly alter history in that it takes existing commits, replaces them with new ones that resemble the old ones, and then pretends that it was like that all along.

[1] In fact, they overlap in areas, and checkout and revert in particular have developed a swiss-army-knife set of commands unrelated to their main purpose. I want to talk about their main purposes here, though. Reset, in particular, has a lot of different uses.

Re: Visualizing Git Concepts with D3.js

#35

Post by Gazler »

robbles wrote: post #8

This is really cool - I wish I'd had this for teaching git a few weeks ago. FYI - it looks like branch creation is broken. Creating a branch and following with `git commit` gives the error "Not a good idea to make commits while in a detached HEAD state." It's not a detached HEAD, it's a branch.

Excuse the self promotion I wrote a tool aimed at teaching git at https://github.com/Gazler/githug

Re: Visualizing Git Concepts with D3.js

#37

Post by touristtam »

Gazler wrote: post #35
robbles wrote: post #8

This is really cool - I wish I'd had this for teaching git a few weeks ago. FYI - it looks like branch creation is broken. Creating a branch and following with `git commit` gives the error "Not a good idea to make commits while in a detached HEAD state." It's not a detached HEAD, it's a branch.

Excuse the self promotion I wrote a tool aimed at teaching git at https://github.com/Gazler/githug

ok, I need to download && install just to see a demo?

Maybe you should create a demo page.

Re: Visualizing Git Concepts with D3.js

#38

Post by touristtam »

smd4 wrote: post #28

Nice work! This is a great complement to the codeschool tutorial [1] it would be nice similarly offer the feature that clicking on the command will auto-populate the virtual terminal. New git users might be more likely to use a client-side GUI where they are clicking buttons rather than typing in the terminal. [1] http://try.github.io/

Oh thanks, never new that one existed. :)

Re: Visualizing Git Concepts with D3.js

#40

Post by stinos »

baddox wrote: post #34

It seems cool, but I don't understand why I can't just click multiple times instead of having to type the command several times. That UI decision makes the site nearly unusable on an iPad.

I think I do understand: the author either did not think this was going to be used on a tablet (after all, it teaches git in it's bare cli form, not by the aid of an point-and-click ui) - or just didn't care about it (for pretty much the same reason, or because he thought there aren't many people using git cli on a tablet anyway).
Post reply on HN