3 ms·

Git might not be hard, it might be easy, but for someone who has not spent enough time trying to understand it, it gives options to royally F up if you don't kn

Git might not be hard, it might be easy, but for someone who has not spent enough time trying to understand it, it gives options to royally F up if you don't know what you're doing. So I make it a point to never use any command other than cherry-pick. Everything else I use GitHub desktop for. Its a simple ui that only lets you do the bare minimum of git actions thats less F up prone. Thats my personal story. The other problem I see is a large number of engineers who say git is not hard, it's very straightforward and they understand it very well, but actually they don't. And every once in a while they royally F up the entire repo and cause issues in deployment because of that. So git's main problem from my perspective is that it's an extremely advanced, unforgiving tool that gives a false sense of expertise to many mediocre programmers.

grayhatter 6y ago
> Git might not be hard, it might be easy, but for someone who has not spent enough time trying to understand it, it gives options to royally F up if you don't know what you're doing. You've just described nearly every tool, show enough carelessness with a hammer and you'll certainly fuck something up. > So I make it a point to never use any command other than cherry-pick. Everything else I use GitHub desktop for. Its a simple ui that only lets you do the bare minimum of git actions thats less F up prone. Yes, when you handicap yourself, limiting to a subset of available features. You'll usually have fewer ways to screw up. But I hope that's not advice you give out to others. That's exactly the mentality I'm trying to encourage people to avoid. "I don't understand it, so instead of trying to learn more about it, I'll just limit my self to a trivial subset of the actual options." That's not how you get good at anything. > Thats my personal story. The other problem I see is a large number of engineers who say git is not hard, it's very straightforward and they understand it very well, but actually they don't. And every once in a while they royally F up the entire repo and cause issues in deployment because of that. Other people making a mistake is pretty common. Sorry you've had to deal with it, I've been there myself. Fixing others mistakes is pretty annoying. It's expecially annoying when they pretend like they already know everything they need to about git; refusing to learn anything new. > So git's main problem from my perspective is that it's an extremely advanced, unforgiving tool that gives a false sense of expertise to many mediocre programmers. Again, it's not extremely advanced. MS Word has more features/options than git does. And I'd never call git unforgiving. In-fact git has been my best friend; I deleted a live directory with a bunch of code that I (foolishly) didn't have backed up anywhere. Including a good portion of the .git directory. Thankfully, git was very forgiving to me, and I was able to restore most of it from the objects that git keeps. But that's something I didn't know how to do before deleting my repo. It's something I had to go out and learn.
- Const-me 6y ago
  > described nearly every tool Good programs aren't that easy to fuck up. Easy when messing with the file system, or deliberately destroying data, but not during normal use. Git is very easy to fuck up even during normal use (multiple people working on a software). > when you handicap yourself, limiting to a subset of available features. Yes. I practice very similar approach as GP, but I use couple other commands too, checkout, reset, clear, bisect. Just because some people wanted a feature, doesn't mean I agree with their estimation of risk/reward. The risk being destroying couple days of other people's work. We were really close one time, didn't happen because my local copy was not yet synced.
  - grayhatter 6y ago
    > Git is very easy to fuck up even during normal use (multiple people working on a software). I disagree that git design is responsible for this. If you have enough people doing something, especially when they all have different subsets of knowledge about the tool they're using. The chance someone will do something incompatible with everyone else rises. Git is clearly more complex than a saw, but give one to enough people who don't understand how to fell a tree, and ask them to build you a deck, oh and you're not allowed to talk to eachother. Something's gonna go badly. > Just because some people wanted a feature, doesn't mean I agree with their estimation of risk/reward. The risk being destroying couple days of other people's work. We were really close one time, didn't happen because my local copy was not yet synced. There's a story here, that I'm interested to hear. But git was kinda designed to avoid this exact thing. There's a reason that your local copy is 100% complete by default. Which means if you really came close to losing a lot of work. All of you were going out of your way to use git in a very not normal way.
    - Const-me 6y ago
      > git design is responsible for this Design of the VCS is almost fine. "Almost" because I would prefer to track renames, but I can live without that. The CLI is horrible. > I'm interested to hear Someone used wrong command-line switch, and the merge commit was made in wrong way, destroying changes made in other branch. Then feature branch was deleted I think. I don't know or care who did that or what was the command-line switch, the point is, the thing is too fragile. People aren't perfect, they make mistakes. Good interfaces are designed in a specific way, to reduce the probability and consequences of these mistakes. In some areas like flight control I think there're even laws about that.
AlexCoventry 6y ago
Just make sure everything is checked in and drop a tag on a known-good commit before any risky operations. You can easily recover to that tag with git reset. There's also the reflog. The github interface probably has a friendly representation of it.

grayhatter 6y ago

> Git might not be hard, it might be easy, but for someone who has not spent enough time trying to understand it, it gives options to royally F up if you don't know what you're doing. You've just described nearly every tool, show enough carelessness with a hammer and you'll certainly fuck something up. > So I make it a point to never use any command other than cherry-pick. Everything else I use GitHub desktop for. Its a simple ui that only lets you do the bare minimum of git actions thats less F up prone. Yes, when you handicap yourself, limiting to a subset of available features. You'll usually have fewer ways to screw up. But I hope that's not advice you give out to others. That's exactly the mentality I'm trying to encourage people to avoid. "I don't understand it, so instead of trying to learn more about it, I'll just limit my self to a trivial subset of the actual options." That's not how you get good at anything. > Thats my personal story. The other problem I see is a large number of engineers who say git is not hard, it's very straightforward and they understand it very well, but actually they don't. And every once in a while they royally F up the entire repo and cause issues in deployment because of that. Other people making a mistake is pretty common. Sorry you've had to deal with it, I've been there myself. Fixing others mistakes is pretty annoying. It's expecially annoying when they pretend like they already know everything they need to about git; refusing to learn anything new. > So git's main problem from my perspective is that it's an extremely advanced, unforgiving tool that gives a false sense of expertise to many mediocre programmers. Again, it's not extremely advanced. MS Word has more features/options than git does. And I'd never call git unforgiving. In-fact git has been my best friend; I deleted a live directory with a bunch of code that I (foolishly) didn't have backed up anywhere. Including a good portion of the .git directory. Thankfully, git was very forgiving to me, and I was able to restore most of it from the objects that git keeps. But that's something I didn't know how to do before deleting my repo. It's something I had to go out and learn.

Const-me 6y ago
> described nearly every tool Good programs aren't that easy to fuck up. Easy when messing with the file system, or deliberately destroying data, but not during normal use. Git is very easy to fuck up even during normal use (multiple people working on a software). > when you handicap yourself, limiting to a subset of available features. Yes. I practice very similar approach as GP, but I use couple other commands too, checkout, reset, clear, bisect. Just because some people wanted a feature, doesn't mean I agree with their estimation of risk/reward. The risk being destroying couple days of other people's work. We were really close one time, didn't happen because my local copy was not yet synced.
- grayhatter 6y ago
  > Git is very easy to fuck up even during normal use (multiple people working on a software). I disagree that git design is responsible for this. If you have enough people doing something, especially when they all have different subsets of knowledge about the tool they're using. The chance someone will do something incompatible with everyone else rises. Git is clearly more complex than a saw, but give one to enough people who don't understand how to fell a tree, and ask them to build you a deck, oh and you're not allowed to talk to eachother. Something's gonna go badly. > Just because some people wanted a feature, doesn't mean I agree with their estimation of risk/reward. The risk being destroying couple days of other people's work. We were really close one time, didn't happen because my local copy was not yet synced. There's a story here, that I'm interested to hear. But git was kinda designed to avoid this exact thing. There's a reason that your local copy is 100% complete by default. Which means if you really came close to losing a lot of work. All of you were going out of your way to use git in a very not normal way.
  - Const-me 6y ago
    > git design is responsible for this Design of the VCS is almost fine. "Almost" because I would prefer to track renames, but I can live without that. The CLI is horrible. > I'm interested to hear Someone used wrong command-line switch, and the merge commit was made in wrong way, destroying changes made in other branch. Then feature branch was deleted I think. I don't know or care who did that or what was the command-line switch, the point is, the thing is too fragile. People aren't perfect, they make mistakes. Good interfaces are designed in a specific way, to reduce the probability and consequences of these mistakes. In some areas like flight control I think there're even laws about that.

AlexCoventry 6y ago

Just make sure everything is checked in and drop a tag on a known-good commit before any risky operations. You can easily recover to that tag with git reset. There's also the reflog. The github interface probably has a friendly representation of it.