On Wed, Jul 16, 2008 at 02:35:16PM -0400, Avery Pennarun wrote: > In svn, a branch is a revision-controlled directory. In git, a branch > is a "ref". What's a ref? Well, it's a name for a commit. What's a > commit? Well, it's a blob. What's a blob? Err, that's complicated. > What happens when I delete a branch? Well, it's still in the reflog. > What's the reflog? Well, it's the local revision history of each > branch. Local? Why not shared? In svn, the revision history of each > branch is shared, but in git, you don't need to, because... > > Even git branches are surprisingly concept heavy, unless your users > ask a lot fewer questions than mine. The really critical question is > why it's so easy to delete a branch in git, and that leads rapidly > into the commit-tree stuff, which is always a spiral into plumbing as > you try to explain the tree of commits. I don't think you need to go into the plumbing to explain the commit tree. What I normally do is tell people that branches point at commits, and that commits are identified by commit ID's, which can be full SHA-1 hashes, or which can be abbreviated for convenience's sake. It's not strictly necessary to tell them about the commit-tree plumbing command; just that each commit creates a snapshot, and that commits can have one or more parents, plus the commit mesage, plus the snapshot. I do absolutely agree with Johannes' assertion that you don't have to explain commit-tree, git-rev-list, and all the rest. The only reason why users will need to see git-rev-list is because git-log references it so prominently, and some of the more powerful git-log options are only documented in git-rev-list. - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
