5 ms·

This is exactly what motivated me to write Learn Git The Hard Way - I was surrounded by people who depended utterly on IDEs and got themselves into terrible sta

This is exactly what motivated me to write Learn Git The Hard Way - I was surrounded by people who depended utterly on IDEs and got themselves into terrible states that based on models that were refractions of what the the (universally available) CLI gives you. The best example of this was when I worked with a project with 12 dev teams that didn't rebase. They asked me where a commit came from, and when I ran 'git log --oneline --graph' the output was all pipes across my (maximized) terminal. I've never seriously gotten into the 'plumbing' of git, so can't claim to have a 'true' vision of git via the CLI, but I've never yet been in a situation where it's been required.

voakbasda 5y ago
Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of the biggest corporations in the world, who build things that will kill people when they fail. I would love to blow the whistle, if I thought that would have any positive outcome whatsoever.
- galangalalgol 5y ago
  I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.
  - jbluepolarbear 5y ago
    I prefer merge/fast forward because I want all history preserved. People can rebase their changes in their branch, but rebasing is never done on the main or development branches. Most of the worst merge conflict I’ve had to deal with were caused by someone rebasing changes they didn’t make. I reject all pull requests that change history.
    - Aeolun 5y ago
      I think this is generally the place where you rebase. Right before things go into the develop branch.
- jjnoakes 5y ago
  In my opinion this is way too much gate keeping. Who defines which tools are "basic tools of the trade" and which are just bland infrastructure? And who decides how much of each tool one should know to move beyond "daily incompetence"? If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool? I'm willing to bet a ton of value has been generated by folks who don't know the first thing about git beyond "commit, push, pull request". Who cares? Now, of course, whatever my core job role is (perhaps it is firmware development, as in your example), I should know that role inside and out if my output is going into safety-critical places. But that's a different comment all together.
  - CRConrad 5y ago
    > In my opinion this is way too much gate keeping. > Who defines which tools are "basic tools of the trade" and which are just bland infrastructure? Well, if so many people routinely have so much difficulty with it as these comments witness, it can hardly be called "bland."
- alisonkisk 5y ago
  The point is that we care about the quality of the software at all times, not elegant graphs of its history.
- BlueTemplar 5y ago
  Huh, how did it get so bad that "blow[ing] the whistle" about "things that will kill people when they fail" "would have [no] positive outcome whatsoever" ?!
- politician 5y ago
  We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.
  - saagarjha 5y ago
    Git is mostly one (clever) data structure.
  - Aeolun 5y ago
    I do actually. If someone can describe to me what the (mechanical) difference is between a merge and rebase they’re likely to be better :P
- jhayward 5y ago
  Oh, boy, do you really want to say that? I have some questions about numerical algorithms that you probably rely on every day for you.
- mattnewton 5y ago
  I disagree, the point is to get code written that solves problems, and the tools are a means to that end and not an end in of themselves. Our tools should make that task easier and more accessible to more people.

voakbasda 5y ago

Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of the biggest corporations in the world, who build things that will kill people when they fail. I would love to blow the whistle, if I thought that would have any positive outcome whatsoever.

galangalalgol 5y ago
I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.
- jbluepolarbear 5y ago
  I prefer merge/fast forward because I want all history preserved. People can rebase their changes in their branch, but rebasing is never done on the main or development branches. Most of the worst merge conflict I’ve had to deal with were caused by someone rebasing changes they didn’t make. I reject all pull requests that change history.
  - Aeolun 5y ago
    I think this is generally the place where you rebase. Right before things go into the develop branch.
jjnoakes 5y ago
In my opinion this is way too much gate keeping. Who defines which tools are "basic tools of the trade" and which are just bland infrastructure? And who decides how much of each tool one should know to move beyond "daily incompetence"? If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool? I'm willing to bet a ton of value has been generated by folks who don't know the first thing about git beyond "commit, push, pull request". Who cares? Now, of course, whatever my core job role is (perhaps it is firmware development, as in your example), I should know that role inside and out if my output is going into safety-critical places. But that's a different comment all together.
- CRConrad 5y ago
  > In my opinion this is way too much gate keeping. > Who defines which tools are "basic tools of the trade" and which are just bland infrastructure? Well, if so many people routinely have so much difficulty with it as these comments witness, it can hardly be called "bland."
alisonkisk 5y ago
The point is that we care about the quality of the software at all times, not elegant graphs of its history.
BlueTemplar 5y ago
Huh, how did it get so bad that "blow[ing] the whistle" about "things that will kill people when they fail" "would have [no] positive outcome whatsoever" ?!
politician 5y ago
We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.
- saagarjha 5y ago
  Git is mostly one (clever) data structure.
- Aeolun 5y ago
  I do actually. If someone can describe to me what the (mechanical) difference is between a merge and rebase they’re likely to be better :P
jhayward 5y ago
Oh, boy, do you really want to say that? I have some questions about numerical algorithms that you probably rely on every day for you.
mattnewton 5y ago
I disagree, the point is to get code written that solves problems, and the tools are a means to that end and not an end in of themselves. Our tools should make that task easier and more accessible to more people.