4 ms·

It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just make

by zajd 10y ago

It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool. Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.

dhimes 10y ago
Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.
- zajd 10y ago
  https://www.atlassian.com/git/tutorials/ https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background
  - dhimes 10y ago
    Thank you.
  - rplst8 10y ago
    Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it. It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
    - dhimes 10y ago
      Right tool definitely wins. Mecurial is excellent, though; it solves all of my problems. But I feel like I should at least know some git basics. And I want to start at the simple beginning just in case I have some misunderstandings about what I'm doing in hg.
    - rkangel 10y ago
      Software allows a better abstraction of a problem than anything in the mechanical world. Progression in software craftsmanship has shown us that powerful functionality can be hidden behind a simple interface, if sufficient thought and design is put into it. Our expectations of how we interact with software have risen over the years, and that's a good thing.
Certhas 10y ago
"It's really not though." That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power. Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws. And I don't work with programmers.
- zajd 10y ago
  It's not an argument because that Koans article is horrible satire that people are trying to pass off as a legitimate argument. I detailed in my post one direct example as to why that post shouldn't be taken seriously. Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which could all be done with aliases) that adds an additional layer of abstraction for no benefit (or at least none that they've felt confident mentioning)
  - Certhas 10y ago
    It wasn't entirely obvious what you were responding to in my post exactly. That article is satire, but if you don't even want to accept that maybe the git commands are badly named (and besides your one bad example, there are plenty of real examples in the satire) I don't see much point in having a discussion. It being "just a wrapper around git" is an excellent argument that the user interface and usability are problematic. Nobody is arguing with the mathematical model underlying git. Gitless manages to expose a lot less state by default. That's a usability win. It's still there when you need it. There is no expressiveness lost. I find the examples they give on their website very persuasive: http://gitless.com/#vs http://gitless.com/#vs If you want the detailed analysis of weaknesses of git that led to the design of gitless, it's here: https://people.csail.mit.edu/sperezde/onward13.pdf https://people.csail.mit.edu/sperezde/onward13.pdf I don't necessarily agree with everything in there but I think it's an excellent analysis overall and worth reading as a case study anyways.
    - zajd 10y ago
      Thank you so much for posting that pdf, that really should be posted somewhere on that site because without the context just throwing out "it's git without a staging area" seems like a pretty poor argument. After reading the whitepaper I would still say that I'm not sure there's much value in the project, that being said they did manage to simplify the "mental model"... although honestly not by much. I'm not sure the cost is worth the benefit here.

by zajd 10y ago

dhimes 10y ago

Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.

zajd 10y ago
https://www.atlassian.com/git/tutorials/ https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background
- dhimes 10y ago
  Thank you.
- rplst8 10y ago
  Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it. It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
  - dhimes 10y ago
    Right tool definitely wins. Mecurial is excellent, though; it solves all of my problems. But I feel like I should at least know some git basics. And I want to start at the simple beginning just in case I have some misunderstandings about what I'm doing in hg.
  - rkangel 10y ago
    Software allows a better abstraction of a problem than anything in the mechanical world. Progression in software craftsmanship has shown us that powerful functionality can be hidden behind a simple interface, if sufficient thought and design is put into it. Our expectations of how we interact with software have risen over the years, and that's a good thing.

Certhas 10y ago

"It's really not though." That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power. Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws. And I don't work with programmers.

zajd 10y ago
It's not an argument because that Koans article is horrible satire that people are trying to pass off as a legitimate argument. I detailed in my post one direct example as to why that post shouldn't be taken seriously. Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which could all be done with aliases) that adds an additional layer of abstraction for no benefit (or at least none that they've felt confident mentioning)
- Certhas 10y ago
  It wasn't entirely obvious what you were responding to in my post exactly. That article is satire, but if you don't even want to accept that maybe the git commands are badly named (and besides your one bad example, there are plenty of real examples in the satire) I don't see much point in having a discussion. It being "just a wrapper around git" is an excellent argument that the user interface and usability are problematic. Nobody is arguing with the mathematical model underlying git. Gitless manages to expose a lot less state by default. That's a usability win. It's still there when you need it. There is no expressiveness lost. I find the examples they give on their website very persuasive: http://gitless.com/#vs http://gitless.com/#vs If you want the detailed analysis of weaknesses of git that led to the design of gitless, it's here: https://people.csail.mit.edu/sperezde/onward13.pdf https://people.csail.mit.edu/sperezde/onward13.pdf I don't necessarily agree with everything in there but I think it's an excellent analysis overall and worth reading as a case study anyways.
  - zajd 10y ago
    Thank you so much for posting that pdf, that really should be posted somewhere on that site because without the context just throwing out "it's git without a staging area" seems like a pretty poor argument. After reading the whitepaper I would still say that I'm not sure there's much value in the project, that being said they did manage to simplify the "mental model"... although honestly not by much. I'm not sure the cost is worth the benefit here.