4 ms·

Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's

by walty8 6y ago

Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.

rusk 6y ago
There are numerous git <-> svn cheat sheets ... this is literally one of the first things I learned. I’m kind of bewildered by this to be honest ... I don’t know how somebody with a technical qualification could have trouble with this ...
- oblio 6y ago
  We shouldn't need a cheat sheet. We shouldn't need Linus's brain dump to be able to use a tool. The Git UI directly models the Git internal model and that's just bad design. It's a completely leaky abstraction. I can use git all right but the fact that I need about 20 different commands to do my job, 95% of them with extra parameters and almost all of them with names that don't reflect what I want to do from a functional point of view is utterly dumb. Again, functional! not technical! The UI should reflect end user functionality, not internal technical details.
  - rusk 6y ago
    I hope I never end up working with you bud. “Where is the code?” “Oh I’m sorry I couldn’t do it because it was hard can I still be paid please?”
    - jodrellblank 6y ago
      I refer to my comment from a couple of days ago: https://news.ycombinator.com/item?id=25080013 https://news.ycombinator.com/item?id=25080013
      - oblio 6y ago
        Oh my, that comment is pure gold :-) Its putting into words something I've been thinking for a long time, thank you for the great comment!
      - rusk 6y ago
        That's just stupid. We're not talking about "users" here, we're talking about "engineers". If you can't grasp the complexity of Git, you've no business using it. You need to be working in an environment with a centralised VCS and somebody administering it. Unless you mean just VCS for yourself, in which case you could probably just use anything you liked rather than complaining about it ... And it's not manliness to say that if you can't grasp complexity you really shouldn't be writing code. That's self evident. It's the whole point of what we do. I'm not looking down on people who can't code - but it's horses for courses. To suggest anything else is just bonkers.
        jodrellblank 6y ago
        You could have read their comment as saying that they have things they'd rather be doing than learning Git. Instead you took the position that expressing a desire for nice tools is a sign of their total incompetence at programming, that they are complaining because they cannot grasp its complexity (despite them saying "I can use Git" which suggests they can grasp its complexity). You dismissed "The Git UI directly models the Git internal model and that's just bad design", launching straight into calling them stupid and saying they need handholding, for merely wanting good design - because good design makes things easier to use, and things being easier to use is for stupid people. You could have argued that Git is easy to use and therefore they are stupid for not being able to use it. Or that the interface modelling the internal workings is a good design. Or that Git's complexity is necessary and no simpler interface is possible. Instead you agree that it is complex and thrill about the complexity and use it as a showoff point about how it makes you superior. That's the manliness part. Not as you willfully misrepresent it "if you can't grasp complexity you really shouldn't be writing code" but "if you don't want to spend your life on the complexity of a supporting tool unrelated to the problem you really want to solve you really shouldn't be writing code". Git is a tool in support of programming, learning Git is not the whole point. Programming involves dealing with complexity (often in the sense of simplifying complexity and hiding it away), but that doesn't mean everything has to be complex to use, and it doesn't mean that someone has to enjoy the complexity in everything to be a good programmer.
    - oblio 6y ago
      With that attitude, I definitely wouldn't want to work with you either. I also love the assumptions about me and the thinly veiled ad-hominem :-) We should be able to admit that a tool has a crap UI and cut out the macho geek attitude. I've been working in this field for about of 15 years and the amount of needless pain we endure from core tools is unimaginable. I'm waaaay past the learning curve for Unix tools, git, etc., but let's not pretend that they're awesome UX wise. They're awful. We've just learned to endure the pain and we've internalized it. Stockholm syndrome at its finest.
      - rusk 6y ago
        I'm really not sure what to say to this. I'm guessing you're not an engineer. It's only product management types that cast around technical criticisms without proposing any solutions so I guess you are of that strain. I don't believe you're stupid, far from it but I think your perspective needs some correction. We've been using VCS fairly universally for the last 25-30 or so. There's been RCS, CVS, SVN, Perforce, Clearcase ... the list goes on. They all have their warts. Git as it stands at this point in time is the best VCS system that the global software development community has come up with. It's exactly as easy to use as the community that developed it needs to be. You are free to explore alternatives. You can get commercial products for this kind of thing, and they may well be easier to use, but in my experience these are more buggy, though they do try to provide a more user friendly experience. You are also free to use the many freely available front-ends to git that are available, or you can use Git in the old centralised model if you like, and go crying to the admin when things get too tricky, as with any other VCS. By far the biggest gripe with Git is the inconsistency of the tooling, and I guess you could fork it and make whatever improvements you feel are appropriate and then set about getting people to use it. But again, there are numerous front ends (IntelliJ is my favourite) that shield you from these minutiae if needs be. So please, spare me your injured animal grandstanding. Git is for the choir, not the masses, and to make it suitable for the masses would be a waste of everybody's time because the masses have no interest. You have an interest that would be better served by just sitting down and learning how to use the damn tools that the rest of your colleagues do. 15 years. LOL. EDIT - if you want something that is "like git" but "easy to use" then, in all seriousness you should check out Mercurial. I always thought it looked nice, but it's of little use if none of my collaborators are on it.
ubercow13 6y ago
It's like shorthand for git checkout <current branch> -- <files>. You're only omitting the current branch which is the default. I'm not sure if it's intuitive but it seems pretty coherent. edit: on second thought no it's really not very coherent. If you exclude <files> it means checkout all files if you write a <branch>, but no files if you write no <branch>. So excluding <branch> doesn't consistently do the same as using <current branch>. I guess git does kind of suck.

by walty8 6y ago

Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.

rusk 6y ago

There are numerous git <-> svn cheat sheets ... this is literally one of the first things I learned. I’m kind of bewildered by this to be honest ... I don’t know how somebody with a technical qualification could have trouble with this ...

oblio 6y ago
We shouldn't need a cheat sheet. We shouldn't need Linus's brain dump to be able to use a tool. The Git UI directly models the Git internal model and that's just bad design. It's a completely leaky abstraction. I can use git all right but the fact that I need about 20 different commands to do my job, 95% of them with extra parameters and almost all of them with names that don't reflect what I want to do from a functional point of view is utterly dumb. Again, functional! not technical! The UI should reflect end user functionality, not internal technical details.
- rusk 6y ago
  I hope I never end up working with you bud. “Where is the code?” “Oh I’m sorry I couldn’t do it because it was hard can I still be paid please?”
  - jodrellblank 6y ago
    I refer to my comment from a couple of days ago: https://news.ycombinator.com/item?id=25080013 https://news.ycombinator.com/item?id=25080013
    - oblio 6y ago
      Oh my, that comment is pure gold :-) Its putting into words something I've been thinking for a long time, thank you for the great comment!
    - rusk 6y ago
      That's just stupid. We're not talking about "users" here, we're talking about "engineers". If you can't grasp the complexity of Git, you've no business using it. You need to be working in an environment with a centralised VCS and somebody administering it. Unless you mean just VCS for yourself, in which case you could probably just use anything you liked rather than complaining about it ... And it's not manliness to say that if you can't grasp complexity you really shouldn't be writing code. That's self evident. It's the whole point of what we do. I'm not looking down on people who can't code - but it's horses for courses. To suggest anything else is just bonkers.
      - jodrellblank 6y ago
        You could have read their comment as saying that they have things they'd rather be doing than learning Git. Instead you took the position that expressing a desire for nice tools is a sign of their total incompetence at programming, that they are complaining because they cannot grasp its complexity (despite them saying "I can use Git" which suggests they can grasp its complexity). You dismissed "The Git UI directly models the Git internal model and that's just bad design", launching straight into calling them stupid and saying they need handholding, for merely wanting good design - because good design makes things easier to use, and things being easier to use is for stupid people. You could have argued that Git is easy to use and therefore they are stupid for not being able to use it. Or that the interface modelling the internal workings is a good design. Or that Git's complexity is necessary and no simpler interface is possible. Instead you agree that it is complex and thrill about the complexity and use it as a showoff point about how it makes you superior. That's the manliness part. Not as you willfully misrepresent it "if you can't grasp complexity you really shouldn't be writing code" but "if you don't want to spend your life on the complexity of a supporting tool unrelated to the problem you really want to solve you really shouldn't be writing code". Git is a tool in support of programming, learning Git is not the whole point. Programming involves dealing with complexity (often in the sense of simplifying complexity and hiding it away), but that doesn't mean everything has to be complex to use, and it doesn't mean that someone has to enjoy the complexity in everything to be a good programmer.
  - oblio 6y ago
    With that attitude, I definitely wouldn't want to work with you either. I also love the assumptions about me and the thinly veiled ad-hominem :-) We should be able to admit that a tool has a crap UI and cut out the macho geek attitude. I've been working in this field for about of 15 years and the amount of needless pain we endure from core tools is unimaginable. I'm waaaay past the learning curve for Unix tools, git, etc., but let's not pretend that they're awesome UX wise. They're awful. We've just learned to endure the pain and we've internalized it. Stockholm syndrome at its finest.
    - rusk 6y ago
      I'm really not sure what to say to this. I'm guessing you're not an engineer. It's only product management types that cast around technical criticisms without proposing any solutions so I guess you are of that strain. I don't believe you're stupid, far from it but I think your perspective needs some correction. We've been using VCS fairly universally for the last 25-30 or so. There's been RCS, CVS, SVN, Perforce, Clearcase ... the list goes on. They all have their warts. Git as it stands at this point in time is the best VCS system that the global software development community has come up with. It's exactly as easy to use as the community that developed it needs to be. You are free to explore alternatives. You can get commercial products for this kind of thing, and they may well be easier to use, but in my experience these are more buggy, though they do try to provide a more user friendly experience. You are also free to use the many freely available front-ends to git that are available, or you can use Git in the old centralised model if you like, and go crying to the admin when things get too tricky, as with any other VCS. By far the biggest gripe with Git is the inconsistency of the tooling, and I guess you could fork it and make whatever improvements you feel are appropriate and then set about getting people to use it. But again, there are numerous front ends (IntelliJ is my favourite) that shield you from these minutiae if needs be. So please, spare me your injured animal grandstanding. Git is for the choir, not the masses, and to make it suitable for the masses would be a waste of everybody's time because the masses have no interest. You have an interest that would be better served by just sitting down and learning how to use the damn tools that the rest of your colleagues do. 15 years. LOL. EDIT - if you want something that is "like git" but "easy to use" then, in all seriousness you should check out Mercurial. I always thought it looked nice, but it's of little use if none of my collaborators are on it.

ubercow13 6y ago

It's like shorthand for git checkout <current branch> -- <files>. You're only omitting the current branch which is the default. I'm not sure if it's intuitive but it seems pretty coherent. edit: on second thought no it's really not very coherent. If you exclude <files> it means checkout all files if you write a <branch>, but no files if you write no <branch>. So excluding <branch> doesn't consistently do the same as using <current branch>. I guess git does kind of suck.