4 ms·

I fucking hope not. Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this. Mercurial and Git were crea

I fucking hope not. Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this. Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect. Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either. Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.

beefsack 9y ago
It's quite frustrating seeing people complain about Git usability like it's some broadly accepted and objectively bad thing. As frivolous as anecdotes are, I took to Git very smoothly and I found it to operate in a very obvious and explicit fashion, particularly once I'd shifted my mental model from what I was using at the time (primarily SVN.) Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.
- stephenr 9y ago
  That's the thing: it is broadly accepted as having poor usability compared to other version control tools. If you haven't had those issues, you're one of the lucky ones. Edit: > Git is a very powerful, flexible, reliable and efficient tool. I didn't say it isn't any of those things. I said it's harder to use than competitors such as mercurial.
  - keymone 9y ago
    could you provide specific examples?
  - ShinTakuya 9y ago
    Do you have a source for this widespread acceptance? I mean I get that version control in general can be hard for new developers to wrap their heads around but I never really had trouble picking up git personally, and the interns at my workplace haven't had any significant trouble either besides needing some coaching in how rebase works.
    - stephenr 9y ago
      This comment (from a Hg developer on Lobste.rs [1]) is a good start: > Furthermore, the proliferation of git wrappers says something. Mercurial has a lot of users too (Facebook), and guess what, they don’t write wrappers for it. They do write aliases and extensions, using hg’s established customisation mechanisms, but they don’t feel like the entire UI is so terrible that it has to be completely replaced by a different UI Then let's consider this snippet, from the people that literally wrote the book on Git, in the Chapter "Git Internals" [2]: > You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners. If you don't know the internals, you don't really know git. I use git for client work on at least a weekly basis - not necessarily daily. I know enough to use it, and enough to know when I need to check the manual or search for something. I don't know the internals, and it's wrong that we 'need' need to. [1]: https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experience_git#c_hukpc8 https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experien... [2]: https://git-scm.com/book/en/v1/Git-Internals https://git-scm.com/book/en/v1/Git-Internals
      - awinder 9y ago
        Careful with equating "Facebook is a wildly market-successful product" with "Every engineering practice at Facebook is industry-applicable and should be emulated".
        stephenr 9y ago
- AndrewBissell 9y ago
  Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all. In fact I remember it being a breath of fresh air from my previous version control experience, which was banging around with TortoiseSVN on Windows. I still remember the first time I used "git cherry-pick," I just guessed what it needed from my (then pretty limited) git experience, and it just worked seamlessly. The few little command-line quirks in git (like "checkout" being used to create new branches) are barely worth mentioning.
  - bildung 9y ago
    >Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all. With all due respect, if you have zero experience with any other CLI solution, are you sure you can evaluate the qualities of git's interface? Nobody said git isn't capable.
    - diggan 9y ago
      Why not? First-time experience with VCS and git compared to first-time experience with git but multi-year experience with others VCS are both valid experiences that has to be considered.
      - stephenr 9y ago
        Nobody is saying Git is unusable, or that it doesn't work, or that it isn't powerful. We're saying the alternatives are easier to use. You freely admit you haven't used any of the alternatives - you haven't even used SVN from a command line, so you have literally nothing to compare to when using git commands.
        diggan 9y ago
        Well, I am not saying that nor admitting to not having used anything else. AndrewBissell above did state that though. My only point being, that while git is not perfect compared to others, even if you don't have experience with an alternative CLI, your experience with just that one CLI can be valuable.
- pwdisswordfish 9y ago
  The UI has some warts, and a few design choices were made that some people find questionable. You can get used to them (which is probably why most people don't even notice it as a problem), but they're there. The best survey of Git's quirks that I've seen is, unfortunately, http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
cthalupa 9y ago
As a not-developer that has to put on a developer hat and learned git and mercurial at about the same time without any prior experience working with cvs/svn/etc outside of checking stuff out from sourceforge, I don't find git to be any more difficult to use than mercurial
laurent123456 9y ago
As far as I understand Linus was mostly involved in creating the git backend, and this part is actually well designed. It looks like something went wrong during the UI development, maybe they've tried to follow the underlying backend too closely instead of thinking it in terms of how users manage their source code.
dang 9y ago
We detached this subthread from https://news.ycombinator.com/item?id=14733364 https://news.ycombinator.com/item?id=14733364 and marked it off-topic.
- stephenr 9y ago
  I don't understand how it's off topic? It was a reply to someone asking if Linus would write his own init (because he's unhappy in systemd), and my take that it would be a bad idea because of the usability issues in the last big thing he started.
  - dang 9y ago
    It's off topic because (a) the subthread became about Git usability, which is not the topic and (b) it's one of those subjects that quickly sucks the oxygen out of other discussions. Not nearly as badly as systemd of course, but still.

beefsack 9y ago

It's quite frustrating seeing people complain about Git usability like it's some broadly accepted and objectively bad thing. As frivolous as anecdotes are, I took to Git very smoothly and I found it to operate in a very obvious and explicit fashion, particularly once I'd shifted my mental model from what I was using at the time (primarily SVN.) Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.

stephenr 9y ago
That's the thing: it is broadly accepted as having poor usability compared to other version control tools. If you haven't had those issues, you're one of the lucky ones. Edit: > Git is a very powerful, flexible, reliable and efficient tool. I didn't say it isn't any of those things. I said it's harder to use than competitors such as mercurial.
- keymone 9y ago
  could you provide specific examples?
- ShinTakuya 9y ago
  Do you have a source for this widespread acceptance? I mean I get that version control in general can be hard for new developers to wrap their heads around but I never really had trouble picking up git personally, and the interns at my workplace haven't had any significant trouble either besides needing some coaching in how rebase works.
  - stephenr 9y ago
    This comment (from a Hg developer on Lobste.rs [1]) is a good start: > Furthermore, the proliferation of git wrappers says something. Mercurial has a lot of users too (Facebook), and guess what, they don’t write wrappers for it. They do write aliases and extensions, using hg’s established customisation mechanisms, but they don’t feel like the entire UI is so terrible that it has to be completely replaced by a different UI Then let's consider this snippet, from the people that literally wrote the book on Git, in the Chapter "Git Internals" [2]: > You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners. If you don't know the internals, you don't really know git. I use git for client work on at least a weekly basis - not necessarily daily. I know enough to use it, and enough to know when I need to check the manual or search for something. I don't know the internals, and it's wrong that we 'need' need to. [1]: https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experience_git#c_hukpc8 https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experien... [2]: https://git-scm.com/book/en/v1/Git-Internals https://git-scm.com/book/en/v1/Git-Internals
    - awinder 9y ago
      Careful with equating "Facebook is a wildly market-successful product" with "Every engineering practice at Facebook is industry-applicable and should be emulated".
      - stephenr 9y ago
AndrewBissell 9y ago
Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all. In fact I remember it being a breath of fresh air from my previous version control experience, which was banging around with TortoiseSVN on Windows. I still remember the first time I used "git cherry-pick," I just guessed what it needed from my (then pretty limited) git experience, and it just worked seamlessly. The few little command-line quirks in git (like "checkout" being used to create new branches) are barely worth mentioning.
- bildung 9y ago
  >Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all. With all due respect, if you have zero experience with any other CLI solution, are you sure you can evaluate the qualities of git's interface? Nobody said git isn't capable.
  - diggan 9y ago
    Why not? First-time experience with VCS and git compared to first-time experience with git but multi-year experience with others VCS are both valid experiences that has to be considered.
    - stephenr 9y ago
      Nobody is saying Git is unusable, or that it doesn't work, or that it isn't powerful. We're saying the alternatives are easier to use. You freely admit you haven't used any of the alternatives - you haven't even used SVN from a command line, so you have literally nothing to compare to when using git commands.
      - diggan 9y ago
        Well, I am not saying that nor admitting to not having used anything else. AndrewBissell above did state that though. My only point being, that while git is not perfect compared to others, even if you don't have experience with an alternative CLI, your experience with just that one CLI can be valuable.
pwdisswordfish 9y ago
The UI has some warts, and a few design choices were made that some people find questionable. You can get used to them (which is probably why most people don't even notice it as a problem), but they're there. The best survey of Git's quirks that I've seen is, unfortunately, http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/

cthalupa 9y ago

As a not-developer that has to put on a developer hat and learned git and mercurial at about the same time without any prior experience working with cvs/svn/etc outside of checking stuff out from sourceforge, I don't find git to be any more difficult to use than mercurial

laurent123456 9y ago

As far as I understand Linus was mostly involved in creating the git backend, and this part is actually well designed. It looks like something went wrong during the UI development, maybe they've tried to follow the underlying backend too closely instead of thinking it in terms of how users manage their source code.

dang 9y ago

We detached this subthread from https://news.ycombinator.com/item?id=14733364 https://news.ycombinator.com/item?id=14733364 and marked it off-topic.

stephenr 9y ago
I don't understand how it's off topic? It was a reply to someone asking if Linus would write his own init (because he's unhappy in systemd), and my take that it would be a bad idea because of the usability issues in the last big thing he started.
- dang 9y ago
  It's off topic because (a) the subthread became about Git usability, which is not the topic and (b) it's one of those subjects that quickly sucks the oxygen out of other discussions. Not nearly as badly as systemd of course, but still.