4 ms·

Huh, another git explanation. Either the thing is so easy to understand that everyone can do it and is then compelled to write about it, or it's so difficult t

by jordigh 12y ago

Huh, another git explanation. Either the thing is so easy to understand that everyone can do it and is then compelled to write about it, or it's so difficult to understand that everyone feels the compulsion to explain it to everyone else.

RickHull 12y ago
Maybe a quip, but that dichotomy is so false it's not even funny. Git is tough to wrap one's head around at first. It's not intuitive unless one already has a deep background in this space. Hence, there are lots of attempts to explain it in order to bring more into the fold of intuition. It seems perfectly natural and good, and your contemptuous tone puzzles me.
- Dylan16807 12y ago
  Right. It's simple but it's unfamiliar. Confusing command parameters aside.
ta0967 12y ago
Its concepts easy to understand and git is very powerful, but the interface is horrible and a bitch to learn. Git does not need another tutorial, it needs an alternative porcelain.
- bsder 12y ago
  git has been out how long now? How many people bitch about its bad user interface? And yet nobody as stepped up to write something better? Perhaps this is pointing to the fact that there is something fundamental about git that prevents such a thing from happening?
  - ta0967 12y ago
    Prevents? There's nothing like that. The only something about git that hampers comprehensive porcelain alternatives is the lack of orthogonality in git's plumbing. People spent years bitching about CVS before a few Apache-related people got together and wrote Subversion. The long time it took didn't point to anything fundamental about CVS preventing anything.
edavis 12y ago
Or, alternatively, git's building blocks are elegant, powerful, and interesting and writing about them makes for natural blog posts/guides/tutorials.
bsder 12y ago
> it's so difficult to understand that everyone feels the compulsion to explain it to everyone else. All successful religions include proselytization in their basic tenets. Ahem. Anyhow. Let me be more charitable. git is so hard to learn because it has an impedance mismatch with the primary user's use case. git clearly works in the large--that's what Linus designed it for. The problem is that git forces you into that workflow immediately and has no intermediate steps. The problem is that most of us use version control to coordinate less than 10 people, and git forces way too much mental energy on top of something which is very simple in CVS or SVN or ... any other version control system, really (maybe arch had a worse mental model ... that's not a compliment). Use Mercurial for a while, and then use git. You will find yourself saying things like: "Why should I need to even care about X?" and the answer is always "Well, if you had 100 committers and 40 branches ..." Things like: "Why would I need to name a branch?" "Why wouldn't I just sync a repository completely?" "Why not just clone the whole repository?" etc. The problem is that everybody is forced into "git in the large" in order to contribute to open source projects. The tutorial that needs to be written is "git in the small", but I'm not sure that the design of git actually allows that tutorial to be written.
- kinghajj 12y ago
  Maybe it's because Git was my first VCS, but I find SVN extremely frustrating to use at work. I'm having troubles understanding the examples you gave, though. Is coming up with (presumably topic) branch names really that hard? Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. What do you mean by "Why wouldn't I just sync a repository completely?" Is this supposed to mean that the concept of private, local branches is confusing? And "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does...
  - bsder 12y ago
    > Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. But how do I merge your "foo" and my "woot"? Um ... why should I even have to care? Why aren't we just working on the same branch by default? > Is this supposed to mean that the concept of private, local branches is confusing? Yes. What happens when I type "git push"? Which of my named branches got transferred? Um ... > "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does... So, is that before or after having been gc'd? Which branches did you get? etc. If there are 3 people generating code artifacts in an office, one of which is an artist, I DON'T CARE about any of these things. Worse, they are wasted mental energy for people who don't like this kind of stuff (the artist, for example, likely doesn't enjoy graph theory). Worst, they are ways that you can corrupt your repository or blow your code away. The fact that I have to think about graph theory to use a DVCS in daily use is unacceptable. It means I can't explain this to writers, artists, and other non-programmers who I would really like to have in source control, too. I explain mercurial vs git like the difference between a high-end chainsaw and a logging chainsaw. A high-end chainsaw has things like safeties, a blade clutch, electric starters, comfortable handles, etc. It will go through 99% of the trees anybody will use it for. A logging chainsaw doesn't have lots of amenities, but the motor is bigger and it will blow through 100% of trees. It's also a hell of a lot heavier which means it's harder to control and more likely to seriously hurt you when something goes wrong.

by jordigh 12y ago

RickHull 12y ago

Maybe a quip, but that dichotomy is so false it's not even funny. Git is tough to wrap one's head around at first. It's not intuitive unless one already has a deep background in this space. Hence, there are lots of attempts to explain it in order to bring more into the fold of intuition. It seems perfectly natural and good, and your contemptuous tone puzzles me.

Dylan16807 12y ago
Right. It's simple but it's unfamiliar. Confusing command parameters aside.

ta0967 12y ago

Its concepts easy to understand and git is very powerful, but the interface is horrible and a bitch to learn. Git does not need another tutorial, it needs an alternative porcelain.

bsder 12y ago
git has been out how long now? How many people bitch about its bad user interface? And yet nobody as stepped up to write something better? Perhaps this is pointing to the fact that there is something fundamental about git that prevents such a thing from happening?
- ta0967 12y ago
  Prevents? There's nothing like that. The only something about git that hampers comprehensive porcelain alternatives is the lack of orthogonality in git's plumbing. People spent years bitching about CVS before a few Apache-related people got together and wrote Subversion. The long time it took didn't point to anything fundamental about CVS preventing anything.

edavis 12y ago

Or, alternatively, git's building blocks are elegant, powerful, and interesting and writing about them makes for natural blog posts/guides/tutorials.

bsder 12y ago

> it's so difficult to understand that everyone feels the compulsion to explain it to everyone else. All successful religions include proselytization in their basic tenets. Ahem. Anyhow. Let me be more charitable. git is so hard to learn because it has an impedance mismatch with the primary user's use case. git clearly works in the large--that's what Linus designed it for. The problem is that git forces you into that workflow immediately and has no intermediate steps. The problem is that most of us use version control to coordinate less than 10 people, and git forces way too much mental energy on top of something which is very simple in CVS or SVN or ... any other version control system, really (maybe arch had a worse mental model ... that's not a compliment). Use Mercurial for a while, and then use git. You will find yourself saying things like: "Why should I need to even care about X?" and the answer is always "Well, if you had 100 committers and 40 branches ..." Things like: "Why would I need to name a branch?" "Why wouldn't I just sync a repository completely?" "Why not just clone the whole repository?" etc. The problem is that everybody is forced into "git in the large" in order to contribute to open source projects. The tutorial that needs to be written is "git in the small", but I'm not sure that the design of git actually allows that tutorial to be written.

kinghajj 12y ago
Maybe it's because Git was my first VCS, but I find SVN extremely frustrating to use at work. I'm having troubles understanding the examples you gave, though. Is coming up with (presumably topic) branch names really that hard? Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. What do you mean by "Why wouldn't I just sync a repository completely?" Is this supposed to mean that the concept of private, local branches is confusing? And "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does...
- bsder 12y ago
  > Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. But how do I merge your "foo" and my "woot"? Um ... why should I even have to care? Why aren't we just working on the same branch by default? > Is this supposed to mean that the concept of private, local branches is confusing? Yes. What happens when I type "git push"? Which of my named branches got transferred? Um ... > "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does... So, is that before or after having been gc'd? Which branches did you get? etc. If there are 3 people generating code artifacts in an office, one of which is an artist, I DON'T CARE about any of these things. Worse, they are wasted mental energy for people who don't like this kind of stuff (the artist, for example, likely doesn't enjoy graph theory). Worst, they are ways that you can corrupt your repository or blow your code away. The fact that I have to think about graph theory to use a DVCS in daily use is unacceptable. It means I can't explain this to writers, artists, and other non-programmers who I would really like to have in source control, too. I explain mercurial vs git like the difference between a high-end chainsaw and a logging chainsaw. A high-end chainsaw has things like safeties, a blade clutch, electric starters, comfortable handles, etc. It will go through 99% of the trees anybody will use it for. A logging chainsaw doesn't have lots of amenities, but the motor is bigger and it will blow through 100% of trees. It's also a hell of a lot heavier which means it's harder to control and more likely to seriously hurt you when something goes wrong.