18 ms·

If y'all think git is hard, wait 'til you hear about computer algorithms! Git isn't hard, it might be complex, but how it works and how to use it is simple as

If y'all think git is hard, wait 'til you hear about computer algorithms! Git isn't hard, it might be complex, but how it works and how to use it is simple as far as applications and/or processes go. I find myself constantly trying to dispel the idea that git is too difficult to understand in depth. The problem has always come down to the missing attempt to understand the issue, over trying to ^c, ^v a solution. Seriously, if you think git is hard: don't ask for it to be easier, ask instead to be stronger. (Or in this case smarter, something you surprisingly have control over)

geitir 6y ago
I think it's more that you have to know git "reflog" instead of some easier non-cryptic command
ramraj07 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. 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.
m463 6y ago
I think git is a very useful tool. That said, the syntax is a little arcane, and it could benefit from a smoother user interface. (like most package managers) As one example, I think the common commands could be separated out from the sort of back-end commands that only experienced users should use.
jariel 6y ago
" constantly trying to dispel the idea that git is too difficult " If that's the case, why wouldn't you concede that it is? "The problem has always come down to the missing attempt to understand the issue" Isn't that always the case with misunderstanding something? That 'it's common' and 'people misunderstand the issue' is essentially proof that at least from a certain level, 'git is hard'. - Git is very powerful. Nobody doubts this. - Git is sometimes easier to understand when the model is well understood - yes, this is a common refrain. But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference. Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation. I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes. I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems. The fact that 'Oh Shit Git' even exists, is in some ways problematic - because it's obviously not clear to many how to truly 'undo' things they've done. OSG could be 100x longer, easily. Have a look here: https://stackoverflow.com/questions/4114095/how-do-i-revert-a-git-repository-to-a-previous-commit/4114122#4114122 https://stackoverflow.com/questions/4114095/how-do-i-revert-... This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers. Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again. It's such an interesting case study from a Product perspective.
- grayhatter 6y ago
  >> "The problem has always come down to the missing attempt to understand the issue" > Isn't that always the case with misunderstanding something? No, some things are difficult. Git might be one of them, but I have no reason to believe that. It's the attempt that's missing. They most often, don't understand git, not because they tried to, and failed. But because they've never really tried to understand the problem. Skipping the part where they find the root cause, actually figured out exactly what's happening, and what's gone awry. They've only searched Stackover flow for the `git reset --hard` command they need. > But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference. As someone who's used a lot of command line tools, I reject this out right. Git is a very simple command line tool. The difficulty is more akin to learning how to use a CLI, not necessarily git itself. Try teaching MS Word to someone while also trying to teach them to write an essay. The missing visual reference will throw people off, but that doesn't make learning how to use it harder. Instead of clicking around for the button that might do something. They have to read something, git --help is super useful. Just like F1 or clicking the help dropdown at the top. > Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation. I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes. I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems. I haven't had these experiences, so I really can't comment. I have to say, I don't really believe people when they say they know and understand git. If someone says they know how to use a chainsaw, do they also know you have to oil it? Knowing how to use something isn't the same as understanding it. Which is what I want people to do.... > Have a look here: > https://stackoverflow.com/questions/4114095/how-do-i-revert-.. https://stackoverflow.com/questions/4114095/how-do-i-revert-.... > This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers. I'm not scared by this at all, so I have no idea what you're talking about. > Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again. Because git is feature rich doesn't mean much. Name a software engineering tool you think is simple/easy, and (if you try to be reasonable,) I'd be willing to bet it has nearly the same, if not more features than git does.
smabie 6y ago
It's not that it's hard or complex, it's that I really don't care about it and am not at all interested in learning. It's a weak attitude, I know, but I just can't help it. So like most other developers, I go about my day totally not understanding git at all and when something weird happens, I talk to that co-worker know understands get (there's always at least one such psychopath on each dev team in existence) and ask him to fix it. He invariably talks about how easy and elegant git is and then finally gets around to giving me a couple commands with non-sensical names and options that fix the problem. I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.
- grayhatter 6y ago
  > there's always at least one such psychopath on each dev team in existence I'm that psycopath :D > I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about. I'm fine with this actually. If you don't care, and don't want to. That's actually totally fine. I personally will look at you a bit strange. But when it comes down to it. You should only care about what you want to. But please, for my continued (admittedly borderline) sanity. Don't try to convince others that it's too hard to learn, and/or that they shouldn't try. I want to work with people who are curious, people who want to learn how cool things work. But there's a trend in software engineering, that parts of it are too hard, and that it's a waste of time to learn them. That's a scary thought to me; imagine the next generation of software devs, all convinced that they can't understand something, or that it would be a waste of their time to try?
  - smabie 6y ago
    I see it like learning a build system: ultimately a pointless piece of trivia that isn't very interesting or worthwhile. This is in contrast to math or CS, which is generalizable and timeless. But you're right, we should all understand this stuff. And if it wasn't for that one magic coworker (you're really taking one for the team), I probably would.
sbuttgereit 6y ago
In some grand sense i think you're right, but your comment fails to appreciate the economics of the issue. I put computer algorithms to work on problems I want to solve; it advances my goals. On the other hand, Git puts me to work on problems that are a necessity of some external requirement or some other purpose in the category of "distraction": I get paid for the computer algorithms part, not the understanding Git part. You are right it's not hard, it's complex. My problem is that my actual problems can be both hard and complex... and putting a complex distraction in the way detracts from my goals: not enhances it. I think many in technology fail to appreciate this distinction. I often hear open source advocates respond to complaints about software quality jumping up to suggest opening issues or contributing fixes... which is fine in its own right: but if those issues/fixes aren't reasonably in line with my own goals in trying to use some class of tool... and some other solutions such as a closed source solution meet the goals more readily... I'm probably not going to spend my time advancing someone else's goals at the expense of my own.
speed_spread 6y ago
The problem with git is not that it's particularly hard to understand, it's that it's the wrong level of abstraction for day to day dev tasks. Git is a great data structure with an arguably bad CLI wrapper. What's missing is a layer of workflow rules specific to each repo. What names should branches have? What are the rules of engagement for PRs? Are rebases preferred over merges? Git doesn't care, nor should it. Yet there's more to creating a branch in a structured dev team than merely typing `git checkout -b new-branch`
AlexCoventry 6y ago
Git cannot fail, it can only be failed.
democracy 6y ago
Code repository tools should be transparent, unfortunately Git very often stands between my changes and the repo. It's funny how other utilities (build pipelines/dependency management/deployments) became more user-friendly in all languages yet the step from SVN was a step in the wrong direction and all thanks to the 'cowboys' with an attitude of "let's use it as if we are a facebook/google or if Linus is using it - it's super cool" without understanding the context where they operate. I can hardly think of a dev tool that became mainstream yet brought so much inefficiency on such a scale into our everyday lives. And when they say 'oh just use these beautiful GUI tools' - oh, wow, we got the same set of tools we had 15 years ago - what an innovation, indeed!
- Const-me 6y ago
  > all thanks to the 'cowboys' with an attitude Maybe cowboys contributed too, but despite horrible interface I think VCS part was actually better. Before everyone switched to git, I’ve used cvs, svn, sourcesafe, clearcase. They all required 2 things to work well: 1. You must be in a room with a low-latency 1GBPs link to the server. 2. Dedicated sys.admins on site whose job is supporting the infrastructure, VCS included. When people don’t screw up with the interface too much, git can be better: doesn’t care about network latency by design, handles conflicts better, branching/merging is very easy…
overgard 6y ago
Its not that it's conceptually hard, the interface just sucks. Like how is "checkout" both for switching branches and also for reverting files? And also it's completely counter to what a "checkout" means in every other VCS. It's just bizarre stuff like that. (I love git, but mercurials interface makes way more sense)
- atq2119 6y ago
  git checkout isn't designed to revert files. It's designed to allow you to check out a particular version of a file without changing the branch you're on. "Reverting a file" is a higher level concept you can build on top of that, but that's not the fault of git checkout. Also arguably to truly revert a file you'd have to follow it up with a git commit. I would also point out that recent versions of git have added a git switch subcommand because of some of these complaints.
  - overgard 6y ago
    Well TIL after using git for 8 years. And yet 90% of the time what I'm typing is "git checkout --" which has nothing to do with the branch of the file, im just getting rid of something. It's a bad UI when the obscure case is favored over the common one, and believe me I can pick out 100 other cases.
    - atq2119 6y ago
      This is interesting. I find myself using checkout to check out individual files extremely rarely. It feels like a bit of an anti-pattern to me. What I do instead is commit the changes I intend to keep, using some interactive form of commit (usually git gui) followed by git reset --hard to remove whatever I don't want to keep. The underlying rule is never to make destructive changes on a working directory that also has changes I intend to keep. This massively reduces the risk of data loss by accidental fat fingering of a command.
P_I_Staker 6y ago
The issue is that many developers don't care about learning to use version control effectively (as a biased git user would see it). They just see it as a means to an end, necessary evil for team projects, but overhead, mostly. They certainly don't want something they need to learn how to use (despite the fact that it's still relatively easy for novice users to do basic things).

geitir 6y ago

I think it's more that you have to know git "reflog" instead of some easier non-cryptic command

ramraj07 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. 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.

m463 6y ago

I think git is a very useful tool. That said, the syntax is a little arcane, and it could benefit from a smoother user interface. (like most package managers) As one example, I think the common commands could be separated out from the sort of back-end commands that only experienced users should use.

jariel 6y ago

" constantly trying to dispel the idea that git is too difficult " If that's the case, why wouldn't you concede that it is? "The problem has always come down to the missing attempt to understand the issue" Isn't that always the case with misunderstanding something? That 'it's common' and 'people misunderstand the issue' is essentially proof that at least from a certain level, 'git is hard'. - Git is very powerful. Nobody doubts this. - Git is sometimes easier to understand when the model is well understood - yes, this is a common refrain. But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference. Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation. I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes. I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems. The fact that 'Oh Shit Git' even exists, is in some ways problematic - because it's obviously not clear to many how to truly 'undo' things they've done. OSG could be 100x longer, easily. Have a look here: https://stackoverflow.com/questions/4114095/how-do-i-revert-a-git-repository-to-a-previous-commit/4114122#4114122 https://stackoverflow.com/questions/4114095/how-do-i-revert-... This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers. Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again. It's such an interesting case study from a Product perspective.

grayhatter 6y ago
>> "The problem has always come down to the missing attempt to understand the issue" > Isn't that always the case with misunderstanding something? No, some things are difficult. Git might be one of them, but I have no reason to believe that. It's the attempt that's missing. They most often, don't understand git, not because they tried to, and failed. But because they've never really tried to understand the problem. Skipping the part where they find the root cause, actually figured out exactly what's happening, and what's gone awry. They've only searched Stackover flow for the `git reset --hard` command they need. > But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference. As someone who's used a lot of command line tools, I reject this out right. Git is a very simple command line tool. The difficulty is more akin to learning how to use a CLI, not necessarily git itself. Try teaching MS Word to someone while also trying to teach them to write an essay. The missing visual reference will throw people off, but that doesn't make learning how to use it harder. Instead of clicking around for the button that might do something. They have to read something, git --help is super useful. Just like F1 or clicking the help dropdown at the top. > Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation. I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes. I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems. I haven't had these experiences, so I really can't comment. I have to say, I don't really believe people when they say they know and understand git. If someone says they know how to use a chainsaw, do they also know you have to oil it? Knowing how to use something isn't the same as understanding it. Which is what I want people to do.... > Have a look here: > https://stackoverflow.com/questions/4114095/how-do-i-revert-.. https://stackoverflow.com/questions/4114095/how-do-i-revert-.... > This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers. I'm not scared by this at all, so I have no idea what you're talking about. > Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again. Because git is feature rich doesn't mean much. Name a software engineering tool you think is simple/easy, and (if you try to be reasonable,) I'd be willing to bet it has nearly the same, if not more features than git does.

smabie 6y ago

It's not that it's hard or complex, it's that I really don't care about it and am not at all interested in learning. It's a weak attitude, I know, but I just can't help it. So like most other developers, I go about my day totally not understanding git at all and when something weird happens, I talk to that co-worker know understands get (there's always at least one such psychopath on each dev team in existence) and ask him to fix it. He invariably talks about how easy and elegant git is and then finally gets around to giving me a couple commands with non-sensical names and options that fix the problem. I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.

grayhatter 6y ago
> there's always at least one such psychopath on each dev team in existence I'm that psycopath :D > I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about. I'm fine with this actually. If you don't care, and don't want to. That's actually totally fine. I personally will look at you a bit strange. But when it comes down to it. You should only care about what you want to. But please, for my continued (admittedly borderline) sanity. Don't try to convince others that it's too hard to learn, and/or that they shouldn't try. I want to work with people who are curious, people who want to learn how cool things work. But there's a trend in software engineering, that parts of it are too hard, and that it's a waste of time to learn them. That's a scary thought to me; imagine the next generation of software devs, all convinced that they can't understand something, or that it would be a waste of their time to try?
- smabie 6y ago
  I see it like learning a build system: ultimately a pointless piece of trivia that isn't very interesting or worthwhile. This is in contrast to math or CS, which is generalizable and timeless. But you're right, we should all understand this stuff. And if it wasn't for that one magic coworker (you're really taking one for the team), I probably would.

sbuttgereit 6y ago

In some grand sense i think you're right, but your comment fails to appreciate the economics of the issue. I put computer algorithms to work on problems I want to solve; it advances my goals. On the other hand, Git puts me to work on problems that are a necessity of some external requirement or some other purpose in the category of "distraction": I get paid for the computer algorithms part, not the understanding Git part. You are right it's not hard, it's complex. My problem is that my actual problems can be both hard and complex... and putting a complex distraction in the way detracts from my goals: not enhances it. I think many in technology fail to appreciate this distinction. I often hear open source advocates respond to complaints about software quality jumping up to suggest opening issues or contributing fixes... which is fine in its own right: but if those issues/fixes aren't reasonably in line with my own goals in trying to use some class of tool... and some other solutions such as a closed source solution meet the goals more readily... I'm probably not going to spend my time advancing someone else's goals at the expense of my own.

speed_spread 6y ago

The problem with git is not that it's particularly hard to understand, it's that it's the wrong level of abstraction for day to day dev tasks. Git is a great data structure with an arguably bad CLI wrapper. What's missing is a layer of workflow rules specific to each repo. What names should branches have? What are the rules of engagement for PRs? Are rebases preferred over merges? Git doesn't care, nor should it. Yet there's more to creating a branch in a structured dev team than merely typing `git checkout -b new-branch`

AlexCoventry 6y ago

Git cannot fail, it can only be failed.

democracy 6y ago

Code repository tools should be transparent, unfortunately Git very often stands between my changes and the repo. It's funny how other utilities (build pipelines/dependency management/deployments) became more user-friendly in all languages yet the step from SVN was a step in the wrong direction and all thanks to the 'cowboys' with an attitude of "let's use it as if we are a facebook/google or if Linus is using it - it's super cool" without understanding the context where they operate. I can hardly think of a dev tool that became mainstream yet brought so much inefficiency on such a scale into our everyday lives. And when they say 'oh just use these beautiful GUI tools' - oh, wow, we got the same set of tools we had 15 years ago - what an innovation, indeed!

Const-me 6y ago
> all thanks to the 'cowboys' with an attitude Maybe cowboys contributed too, but despite horrible interface I think VCS part was actually better. Before everyone switched to git, I’ve used cvs, svn, sourcesafe, clearcase. They all required 2 things to work well: 1. You must be in a room with a low-latency 1GBPs link to the server. 2. Dedicated sys.admins on site whose job is supporting the infrastructure, VCS included. When people don’t screw up with the interface too much, git can be better: doesn’t care about network latency by design, handles conflicts better, branching/merging is very easy…

overgard 6y ago

Its not that it's conceptually hard, the interface just sucks. Like how is "checkout" both for switching branches and also for reverting files? And also it's completely counter to what a "checkout" means in every other VCS. It's just bizarre stuff like that. (I love git, but mercurials interface makes way more sense)

atq2119 6y ago
git checkout isn't designed to revert files. It's designed to allow you to check out a particular version of a file without changing the branch you're on. "Reverting a file" is a higher level concept you can build on top of that, but that's not the fault of git checkout. Also arguably to truly revert a file you'd have to follow it up with a git commit. I would also point out that recent versions of git have added a git switch subcommand because of some of these complaints.
- overgard 6y ago
  Well TIL after using git for 8 years. And yet 90% of the time what I'm typing is "git checkout --" which has nothing to do with the branch of the file, im just getting rid of something. It's a bad UI when the obscure case is favored over the common one, and believe me I can pick out 100 other cases.
  - atq2119 6y ago
    This is interesting. I find myself using checkout to check out individual files extremely rarely. It feels like a bit of an anti-pattern to me. What I do instead is commit the changes I intend to keep, using some interactive form of commit (usually git gui) followed by git reset --hard to remove whatever I don't want to keep. The underlying rule is never to make destructive changes on a working directory that also has changes I intend to keep. This massively reduces the risk of data loss by accidental fat fingering of a command.

P_I_Staker 6y ago

The issue is that many developers don't care about learning to use version control effectively (as a biased git user would see it). They just see it as a means to an end, necessary evil for team projects, but overhead, mostly. They certainly don't want something they need to learn how to use (despite the fact that it's still relatively easy for novice users to do basic things).