5 ms·

I think the point of the article was that he shouldn't have to edit his ssh settings to use Git.

by cosmo7 18y ago

KirinDave 18y ago
And he doesn't have to. ssh-keys is just a convenience. Most of the complaints in this article can be restated as, "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." With the multiple-user-account issue being more of a github logistics than anything else (if you host your own repo, you have the entire unix permissions model is available to you). Everyone knows git is weird and new and has a much more complex interface than SVN, but the tradeoff is that you get an extremely powerful and flexible version control system.
- DenisM 18y ago
  >> "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful.
  - KirinDave 18y ago
    >> It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful. We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles. And given how trivial it is to find and read such data, my sympathy is limited. What's more, git's usability is a radical improvement path. Between services for remote repos (like github and gitorious) and better and better command line tools (GitX, for example). At some point you have to bite the bullet and understand your tools. We're seeing a lot of this reluctance in the industry as people are forced to confront distributed concepts.
    - DenisM 18y ago
      I guess the question is which part of the learning curve is there for a reason and which part is preventable. Someone has already asked the question - is Mercurial any less powerful for being easier to use? I am sitting on the sidelines (svn) and waiting for the dust to settle. My only interest is to have one dcvs emerge with all the best in it that this field can offer.
      - KirinDave 18y ago
        Mercurial is marginally less powerful (it's maybe 6 months behind git in features, perpetually). This is not a deal-breaker (except that I don't like Mercurial's equivalent of cheap local branches, these patch queues are just an awkward model for thinking about it), but then there is the speed issue. Git is incredibly fast, so fast that you almost never notice it working even for massive amounts of data.
    - timr 18y ago
      "We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles." My job is not to spend time understanding how to use the version-control flavor of the week -- my job is to write software. You may not realize it, but you're advancing the usual, dressed-up, ad hominem attack of the perspective-challenged nerd: "tool Y is EASY if you just try to learn it!" (the implication being that if you don't want to spend time on a yak-shaving expedition to learn tool Y -- when tool X works just fine -- then you're lazy, dumb, or both.) Version control is a tool. Good tools let me do my job and get out of the way. Bad tools force me to spend a lot of time "understanding" them before I can be productive.
      - thwarted 18y ago
        No one is telling you you have to learn how to use the version-control flavor of the week if your project doesn't currently use it and your project is serviced just fine by some other version control flavor that everyone is already familiar with and is productive using. However, it's isn't very productive to have to deal with the same problems every day when using tool X, especially if taking a few hours to learn tool Y and switch to it would solve those problems.

I think the point of the article was that he shouldn't have to edit his ssh settings to use Git.

by cosmo7 18y ago

I think the point of the article was that he shouldn't have to edit his ssh settings to use Git.

And he doesn't have to. ssh-keys is just a convenience. Most of the complaints in this article can be restated as, "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." With the multiple-user-account issue being more of a github logistics than anything else (if you host your own repo, you have the entire unix permissions model is available to you). Everyone knows git is weird and new and has a much more complex interface than SVN, but the tradeoff is that you get an extremely powerful and flexible version control system.

DenisM 18y ago
>> "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful.
- KirinDave 18y ago
  >> It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful. We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles. And given how trivial it is to find and read such data, my sympathy is limited. What's more, git's usability is a radical improvement path. Between services for remote repos (like github and gitorious) and better and better command line tools (GitX, for example). At some point you have to bite the bullet and understand your tools. We're seeing a lot of this reluctance in the industry as people are forced to confront distributed concepts.
  - DenisM 18y ago
    I guess the question is which part of the learning curve is there for a reason and which part is preventable. Someone has already asked the question - is Mercurial any less powerful for being easier to use? I am sitting on the sidelines (svn) and waiting for the dust to settle. My only interest is to have one dcvs emerge with all the best in it that this field can offer.
    - KirinDave 18y ago
      Mercurial is marginally less powerful (it's maybe 6 months behind git in features, perpetually). This is not a deal-breaker (except that I don't like Mercurial's equivalent of cheap local branches, these patch queues are just an awkward model for thinking about it), but then there is the speed issue. Git is incredibly fast, so fast that you almost never notice it working even for massive amounts of data.
  - timr 18y ago
    "We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles." My job is not to spend time understanding how to use the version-control flavor of the week -- my job is to write software. You may not realize it, but you're advancing the usual, dressed-up, ad hominem attack of the perspective-challenged nerd: "tool Y is EASY if you just try to learn it!" (the implication being that if you don't want to spend time on a yak-shaving expedition to learn tool Y -- when tool X works just fine -- then you're lazy, dumb, or both.) Version control is a tool. Good tools let me do my job and get out of the way. Bad tools force me to spend a lot of time "understanding" them before I can be productive.
    - thwarted 18y ago
      No one is telling you you have to learn how to use the version-control flavor of the week if your project doesn't currently use it and your project is serviced just fine by some other version control flavor that everyone is already familiar with and is productive using. However, it's isn't very productive to have to deal with the same problems every day when using tool X, especially if taking a few hours to learn tool Y and switch to it would solve those problems.