6 ms·

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 com

by mattip 12y ago

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.

kinghajj 12y ago
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.
- privong 12y ago
  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.
  - mrchlblng 12y ago
    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
    - privong 12y ago
      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.
      - bch 12y ago
        > 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...
- bch 12y ago
  > 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/
  - tedks 12y ago
    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?
  - kbar13 12y ago
    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.
    - bch 12y ago
      > 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 http://fossil-scm.org
VLM 12y ago
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.
jmount 12y ago
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)
- dalai 12y ago
  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.
  - jmount 12y ago
    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.
cglee 12y ago
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 http://www.gotealeaf.com/books/git

by mattip 12y ago

kinghajj 12y ago

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.

privong 12y ago
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.
- mrchlblng 12y ago
  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
  - privong 12y ago
    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.
    - bch 12y ago
      > 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...
bch 12y ago
> 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/
- tedks 12y ago
  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?
- kbar13 12y ago
  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.
  - bch 12y ago
    > 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 http://fossil-scm.org

VLM 12y ago

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.

jmount 12y ago

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)

dalai 12y ago
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.
- jmount 12y ago
  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.

cglee 12y ago

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 http://www.gotealeaf.com/books/git