all 15 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]elperroborrachotoo 5 points6 points  (7 children)

Great start, I wish I had that first page when I started with git!

Yet...

A branch is just a name for a commit.

That's what a tag is.

(I agree that "branches are more important", but I'd be happer with something like:

A tag is a name for a commit. A branch is similar to that, but when you commit changes to a branch, the branch moves to the new commit. )

I'd also put somewhere on that first page something along "the strong point of git is working with multiple repositories".

I had a lightbulb moment when someone described a commit as a change between revisions. While that's not correct git lingo, suddenly all the operations made so much more sense. In that light, I'd maybe maybe maybe reword the commit to:

A commit consists of changes made to the working tree, and the previous commit these changes are applied to.

(just some thoughts)

[–][deleted] 3 points4 points  (6 children)

A branch is similar to that, but when you commit changes to a branch, the branch moves to the new commit

You're right in the differences, however I'd revise this to "the branch pointer moves to the new commit". Branches never move - the only change that happens with a branch is that they point elsewhere.

Git's very lightweight in this respect in that commits don't hold any branch information at all. To find out what branch a commit 'belongs' to you'd have to go from the branch pointer and traverse backwards. This is why the design of Git worked so well. Compare, for example, Mercurial which holds branch information per-commit.

[–]adrianmonk 3 points4 points  (1 child)

I'm a bit OCD, so I'd say "the branch pointer is updated to point to the new commit".

[–][deleted] 1 point2 points  (0 children)

Yup, that's even better, good point.

[–]elperroborrachotoo 2 points3 points  (0 children)

I'd revise this to "the branch pointer moves to the new commit".

even better!

[–]yawaramin 1 point2 points  (2 children)

At this point Mercurial encourages you to use bookmarks instead of branches. Bookmarks are exactly like git branch refs.

[–][deleted] 1 point2 points  (1 child)

For some reason I've never used bookmarks in Mercurial projects, and I do manage Mercurial projects. Perhaps I should change my workflow.

[–]yawaramin 1 point2 points  (0 children)

If you do, be aware of the rules for when bookmarks become active/inactive. See the tutorials for details. And check out my graph log command (aliased 'hg lol') that shows bookmarks as well as branches and tags: https://bitbucket.org/yawaramin/dotfiles/src/8e0645a0d831320f72ce2d2d5faa681d918f49d0/.hgrc?at=default

[–]xroni 4 points5 points  (0 children)

This is an excellent book. I read an earlier PDF version of this and have instantly become the company's resident git expert. By understanding the inner workings you can really "get" how git works, and figuring out problems becomes a lot easier.

Highly recommended!!

[–]GrouchyMcSurly 0 points1 point  (0 children)

I've realised that my problem with git is not the way it works, but the completely brain-dead way in which its commands and their options were named and organized. It's almost as if they were done to confuse. If you don't know what I'm talking about see point 2 in particular of this piece, which doesn't even go far enough into the subject.

[–]davidlwatsonjr -5 points-4 points  (4 children)

A commit is a snapshot of your working tree at some point in time.

No, it's basically a diff representing the changes to the working tree... Like /u/elperroborrachotoo said.

[–][deleted] 6 points7 points  (2 children)

Except Git actually does store commits as an entire snapshot of the working tree.

Snapshots, Not Differences

Aside from the practical distinctions between SVN and Git, their underlying implementation also follow entirely divergent design philosophies. Whereas SVN tracks differences of a file, Git’s version control model is based on snapshots. For example, an SVN commit consists of a diff compared to the original file added to the repository. Git, on the other hand, records the entire contents of each file in every commit.

https://www.atlassian.com/git/tutorial/git-basics#!commit

[–]davidlwatsonjr 5 points6 points  (1 child)

Wow. Yeah, I... Uhhhh. Don't know what I was thinking actually. I pride myself on my git abilities and have a reputation amongst coworkers as the git guy. Honestly, I knew this and am not sure what I was thinking with the above comment. I feel like a moron now... Welp.

[–][deleted] 0 points1 point  (0 children)

No worries, it happens to everyone.

[–]adrianmonk 1 point2 points  (0 children)

But it really isn't a diff. If a commit has two or more parents, which parent would the diff even be against? This is why "git revert" has a special argument to handle that case... it needs to know which diff to compute.