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

Learn Git Branching

pcottle.github.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Learn Git Branching

#91

Post by xxbondsxx »

Flimm wrote: post #70
Flimm wrote: post #69

C1' has two meanings, one is the result of a rebase, and one is the result of a revert. I stared at level 2 of "master the rebase, Luke" for a while before I realised this. I think these two things should be have different notations (maybe C1' and C1^-1, or C1' and C1r).

In fact, I solved that level using only 'git revert' commands, which I don't think was the intended solution. And the displayed solution isn't complete: it asks the user to perform an interactive rebase. (I'm not complaining, just feedback.)

That's a good point. I should just disable revert in all levels except for those related to it. I rarely revert in practice so it's not a huge issue.

Showing the concept of a "modified" commit is hard though. That's why I did all the C1' sillyness (like the man pages do). The apostrophes also scale nicely (up to C1'^99) where reverting a reverted rebased commit might make the text too big.

EDIT: Fixed, see: https://github.com/pcottle/learnGitBranching/issues/7

Re: Learn Git Branching

#92

Post by xxbondsxx »

ecoffey wrote: post #62

This is really really great. Good visualizations of how git works are really awesome and useful, so thanks! That said, the intro lesson introduces commits as exclusively deltas. This isn't accurate, and would probably cause confusion with later concepts. Commits are really snapshots of a tree object (with probably a whole lot of sub trees, and a whole lot of blobs). Since part of the commit meta-data is the parent sh…

Discussion here, I'm updating as we speak:

https://github.com/pcottle/learnGitBranching/issues/6

Re: Learn Git Branching

#94

Post by xxbondsxx »

aymeric wrote: post #93

Would be nice to see the solution of a level, to compare it with what we have done (and to find the solution if we are stuck).

You can type in "show solution" to see the solution for a level (after a prompt). I'll have to add this to some help dialog somewhere...

(again I apologize about the discoverability for different commands -- was going to document all this before submitting)

Re: Learn Git Branching

#95

Post by xxbondsxx »

dljsjr wrote: post #68
xxbondsxx wrote: post #51

Earlier quoted context omitted.

I just pushed the site live, so it starts off with a help dialog and links to the demo. Future visitors should hopefully get a better experience! My apologies again -- I only noticed it was on HN when I got an email about it...

Your use of live visualizations of the state of the repository is probably the single best part of the app. Seriously, very very well done.

Thanks! Really appreciate the feedback, I worked really hard on the animations and there were a ton of corner cases to solve in order for them to work. But I do think they serve a huge educational value, so I'm glad to hear the work (and code) paid off.

Re: Learn Git Branching

#96

Post by mappum »

My only criticism is that there a million modals you have to go through, and some are even multi page, adding complexity. I would rather have fewer modals/pages that show more text at once.

But overall, this is super handy, great idea :)

Re: Learn Git Branching

#97

Post by [deleted] »

benihana wrote: post #90
xxbondsxx wrote: post #27

Wow! Author here, did not expect this to get submitted to HN yet (was going to finish out a few more levels this weekend and clean everything up). Forgive the giant "TODO" in the help dialog The link everyone should see is the demo: http://pcottle.github.com/learnGitBranching/?demo That shows a few example commands, the completion of a level, and finishes with the help dialog. Some interesting technical highlights -…

What's the point of having a close button on a dialog window that doesn't close the dialog?

[deleted]

Re: Learn Git Branching

#98

Post by mbell »

benihana wrote: post #90
xxbondsxx wrote: post #27

Wow! Author here, did not expect this to get submitted to HN yet (was going to finish out a few more levels this weekend and clean everything up). Forgive the giant "TODO" in the help dialog The link everyone should see is the demo: http://pcottle.github.com/learnGitBranching/?demo That shows a few example commands, the completion of a level, and finishes with the help dialog. Some interesting technical highlights -…

What's the point of having a close button on a dialog window that doesn't close the dialog?

I also found this really confusing, just in general the "OSX window" design made me think I could close them, minimize them, move them, etc (which would have been really useful, especially the 'goal' window).

The app in general is supremely awesome though, I love it, I hope github hires the author to fully flesh it out and make it part of their tutorial. It is insanely useful for people whom are new to git.

Re: Learn Git Branching

#100

Post by Cogito »

xxbondsxx wrote: post #77
archgoon wrote: post #55

This tutorial is great, but it propagates a misconception about git. "A commit in git is a recorded set of changes that you have made" Git commits are _not_ deltas. They are entire snapshots of the repository and a single (optional) pointer to an ancestor commit[1]. Git may handle _compression_ in terms of deltas (see 'Packfiles' in [2]), but logically, a commit should be thought of as equivalent to the state of all…

Thanks a ton for catching this. I guess there is a distinction to be made -- the compression might use delta's, but a commit specifies the entire state of the repository. It's a tricky line to walk though, because commands like "git show" and "git patch" clearly show the delta-like nature of a single commit. I also don't want newcomers to think that commits are heavy and should be used sparingly. I'm totally down to…

This is still not quite correct. Let me outline the structure, and then I will try and submit a PR addressing it.

The first step to committing is staging what should be included.

The staging process specifies an index of files that are to be added to the next commit. When the commit is recorded, git checks every file/chunk in the index; a hash is calculated per each of these blobs, each blob and hash are stored in a keyobject store, the object store, and the hashes are written into the index of the commit.

If a blob already exists in the store then it is not added again.

When changes are made and committed after this point, the resulting blobs are then hashed and stored again. Any unchanged blob does not need to be stored again; any changed blobs are stored.

When a commit is recreated, it's index is evaluated. Each blob is retrieved from the object store and placed into the tree in the appropriate location.

The most important thing to take out of this? Rebuilding a tree from blobs is fast. Second thing to take out? Git only stores each version of a blob (be it a file or a chunk) once, so most 'unpacked' repositories are still quite small.

Now, this is obviously not the smallest representation of the repository, so git has a packed format which calculates deltas between blob files. This will calculate blob-deltas even if they are completely separated in the history; deltas are not between commits, instead they are between objects. Unpacking deltas recreates the blob objects required to build the tree.

The packing process happens every now and then, but it is definitely not done every time a commit is made (by default). The most visible place it is used is when transferring over network protocols (I can't recall if it is done for every network transfer, but I suspect it is). It is done when running garbage collection as well.

----

The reason why all this is important is as I laid out before: rebuilding trees is fast, which makes fast branching possible, and the object store allows this without exploding the size of the repository.

Post reply on HN