6 ms·

It would seem that some of these git "problems" can be solved the way you'd automate anything else in Unix...write your own scripts or aliases. Tools are not s

It would seem that some of these git "problems" can be solved the way you'd automate anything else in Unix...write your own scripts or aliases. Tools are not supposed to please everybody. (They can't, since for every person who loves the default configuration, there will be someone who doesn't.) If you can't remember that "foo -bar -baz -squareroot4515" is the command to do X, then make a shell alias or a script that performs these steps for you, and call it whatever you want.

cosmo7 18y ago
I think the point of the article was that he shouldn't have to edit his ssh settings to use Git.
- 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.

cosmo7 18y ago

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

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.