3 ms·

> 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 describ

by 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
  - kaishiro 12y ago
    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.
    - dalai 12y ago
      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.
      - kaishiro 12y ago
        But surely we all understand that the "best" tool doesn't always win the day, right?
Crito 12y ago
> "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.

by bch 12y ago

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
- kaishiro 12y ago
  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.
  - dalai 12y ago
    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.
    - kaishiro 12y ago
      But surely we all understand that the "best" tool doesn't always win the day, right?

Crito 12y ago

> "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.