Hacker News Reader

Comment by mattip | Hacker News Reader

The main gripe I have with many git tutorials is how quickly I am exposed to git internals, before even describing how to do basic things like "get the last commit id" or " find where a file changed". I am only slightly interested in the tree structure used to store my data, and as a beginner much more interested in cooperative work flow with a group of developers.

View on HN

To me, it is one of Git's strengths, that it's internal data structure is simple enough to describe and understand, and doing so brings great clarity to the rest of its operations. For example, knowing that "creating a branch" is literally just writing 40 bytes to a file makes them much more approachable.

> To me, it is one of Git's strengths, that it's internal data structure is simple enough to describe and understand

I find it's _not_ simple enough to describe and understand, and that it almost seems _necessary_ to know it, which takes up cognitive attention/space. I feel like it's a failure of design (poor abstraction, or simply bad engineering) that these sorts of introductions are rehashed over and over and over again. I suspect Git is only popular because

1) Cult of Linus

2) Github

Otherwise, there are other capable more pleasant tools to use...

edit: formatting, s/Linux/Linus/

> "I find it's _not_ simple enough to describe and understand"

I mean, you've got tree, commit, and blob objects, and they only compose in very limited ways. trees can have blobs or trees. Commits can have commits or trees. Blobs don't contain other objects. There are also tag objects, but you don't often need to think about those.

That's pretty damn simple. It's really only a single (very simple) concept more complicated than what filesystems expose to end users (trees and blobs, err I mean, directories and files).

The payoff of spending one or two minutes learning these very basics is that you will be able to derive the answer to "Can git do..." formatted questions without little effort. Not having to resort to documentation or google for those kind of questions saves me tons of time and grief.

Like with most things, popularity is not derived from what you expect, yet popularity exists for good reason. Git may or may not be perfect, depending on your point of view. However, it's more than sufficient to do the job, and it does the job pretty darn well. The other factor is that it's popular because.... it's popular.

Yes, it's a good idea to take on git because other people use it. It's not a personal tool like your text editor where you can lord over your little realm and customize the crap out of it. git is a collaboration tool.

> Like with most things, popularity is not derived from what you expect

I listed what I suspect...

> yet popularity exists for good reason.

Are you talking about cause or effect ? Does it matter ?

> Git may or may not be perfect, depending on your point of view.

It's not, _nearly_ certainly regardless of ones PoV

> However, it's more than sufficient to do the job, and it does the job pretty darn well.

It's used a lot, and mostly works, sure.

> The other factor is that it's popular because.... it's popular.

What "other factor" is this? I was talking about what I consider weak points and poor engineering -- I'm not denying it's popular... it's practically a verb (people say "git" where "source control management", or "distributed source control management" is what they mean...)

> Yes, it's a good idea to take on git because other people use it.

Network effect, I get it...

> It's not a personal tool like your text editor where you can lord over your little realm and customize the crap out of it.

Well... not everybody is managing the Linux kernel. Not everybody is even collaborating. I use fossil[0] because I'd rather enjoy my development process. It _works_ for me. I don't care if Linus uses git, or if some high-profile codebase is managed by git.

> git is a collaboration tool.

And so are fossil and mercurial. And I've run _many_ projects under fossil, including ~20-person distributed (cross-country) projects that include development, configuration, and release management. No git necessary.

I not saying git isn't popular, or can't do its job. I'm saying: Its a bit hard to understand why git (which I suggest is unnecessarily difficult) is so popular -- I listed my two suspicions.

[0] http://fossil-scm.org

Just to add another anecdotal point on top of your own. I use git because it gets the jobs done. I don't remotely care that Linus uses it. I've honestly never ran into issues even on 20 person+ teams using simple branch & rebase strategies. To each their own.

I am not sure what your point is. Subversion, git, hg, darcs all get the job done. Was your choice of git based on its superiority over the other ones or just a side effect of its popularity? The problem with git is not that you will run into issues, it is that other vcs provide a saner ui and require less of their users without missing on features.

But surely we all understand that the "best" tool doesn't always win the day, right?

Yes, things are generally only existent if they are either popular or good (or very new). There's git, and there's mercurial in the world of DVCS. Which is popular? Which is good?

But the parent's point is that this internal data structure is irrelevant to the absolute beginner, who is trying to figure out how to use git, as opposed to figuring out how git works under the hood. It is great that the internal data structure is fairly simple, but that does not necessarily mean it should be brought up so early in tutorials. It can be a turn off to people who are learning version control tools for the first time.

From my experience, most people issues with git is because they do not really understand how it works (or try to apply what they've seen with other cvs). Now I agree that having to understand internals might be seen as an engineering failure, however * internals are pretty quick to cover * for students learning software development, I thought it would be interesting to see that you can have very few low-level objects that offer powerful high-level actions

I can see where those things would be interesting for students learning software development, but not everyone who uses git is doing that type of development. To be fair, I am coming at this from the standpoint of someone who uses git for science, rather than software development. Yes, I use it to track changes in code, but vast majority of that code is scripting analysis procedures (so knowing about internal data structures does not directly help me do my job). I also use git to track changes in LaTeX manuscripts. So, while your first point is arguably universally applicable (that knowing the internals would help me use git), the second point does not apply to everyone.

I am not suggesting that all tutorials should jettison an early discussion of the git internals, but merely suggesting that including such a discussion early on, may not be appropriate for some audiences.

> To be fair, I am coming at this from the standpoint of someone who uses git for science, rather than software development

As a software developer, I would rather spend my time on the task at hand (my own development) rather than git internals. I don't understand why so many people apologize for the (imo) poor user-experience that git provides...

Oddly enough I think that is one of the reasons Git is popular: you are exposed early to a learnable mental model. (edit: it is a model of Git's storage interface, not a model of version control or a model of storage implementation)

Honestly, since when is that a great feature? I can't think of any other piece of modern software that requires that of its users (other dvcs with similar feature sets included). Noone should care about "internal" interfaces, no matter if they are easy to learn or not.

Programmers are pretty used to building mental models. And my point was that at least you can learn the git internals, but other "everything magic happens but we don't let you even reason how" source control systems are even less learnable than Git.

I would agree with and extend your remarks that stereotypically all git books begin with creating a nice clean repo and all git users begin by being thrown into the deep end with an existing project.

Rather than writing the tutorial starting from nothing and creating a repo and entering its first commit, it might be very interesting to write a tutorial starting from a simple artificial repo with just a couple branches and commits.

I believe this tendency comes from programming where "the book" usually starts with typing in hello world, but the real world usually starts with maint work on existing code.

I still git-flow, I donno if thats cool or not. HN is extremely fad focused so its possible half the readership don't even know what git flow is/was because it was cool waaaaay back when nosql was going to save us all. It would be interesting if the tutorial reflected git flow or possible alternatives.

Here's a very beginner friendly guide on git and Github. It's for people who may have never used version control in the past: http://www.gotealeaf.com/books/git

Reply on news.ycombinator.com