4 ms·

I'm one of the git "experts" that occasionally helps unwedge people who are "wedged" with git. Every time, they are mentally unwilling to learn git. And befor

I'm one of the git "experts" that occasionally helps unwedge people who are "wedged" with git. Every time, they are mentally unwilling to learn git. And before anyone mistakes that for complexity on git's side… often, these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff.

crgwbr 7y ago
It’s alarming how true this is. Many seem almost proud of the fact that they have no idea how to use their tools. That’s definitely not git’s fault.
- cogman10 7y ago
  I knew a team of devs whose workflow with git was to have a clone of the repo per branch they worked on. Needless to say, this caused a bunch of issues that made them think git was bad. When I asked "why don't you just checkout the branch you want to work on?" The answer I got was "I don't like working that way... Now fix my horrible mess of esoteric git features that I misapplied"
woutr_be 7y ago
> these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff. I've seen people like this too, when reviewing PRs, I often see unwanted code being committed, and I just don't understand why this keeps happening. One of my defaults when committing code is to run "git status", then run "git diff" on each file I'm committing. I thought this was a pretty well used flow, but apparently it's not.
- honestoHeminway 7y ago
  A snake only encounters birds frozzen in fear
- u801e 7y ago
  I tell people to run git log -p --reverse origin/master.. and git diff origin/master.. to see what changes their commits are introducing and the overall change they're making before they actually push the branch up to the remote. It's essentially proofreading what you're going to submit before actually submitting it.
- syncsynchalt 7y ago
  Or better yet: `git add -p` If you only ever use `git add -N .` and `git add -p` you'll never have unexpected changes in your commit.
  - cryptonector 7y ago
    Or better yet: `git add -e`.
BeetleB 7y ago
> And before anyone mistakes that for complexity on git's side… often, these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff. And yet I don't run into such behavior from people using SVN or mercurial.
- plorkyeran 7y ago
  Every SVN-using project I've touched has had countless examples of files accidentally being committed.

crgwbr 7y ago

It’s alarming how true this is. Many seem almost proud of the fact that they have no idea how to use their tools. That’s definitely not git’s fault.

cogman10 7y ago
I knew a team of devs whose workflow with git was to have a clone of the repo per branch they worked on. Needless to say, this caused a bunch of issues that made them think git was bad. When I asked "why don't you just checkout the branch you want to work on?" The answer I got was "I don't like working that way... Now fix my horrible mess of esoteric git features that I misapplied"

woutr_be 7y ago

> these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff. I've seen people like this too, when reviewing PRs, I often see unwanted code being committed, and I just don't understand why this keeps happening. One of my defaults when committing code is to run "git status", then run "git diff" on each file I'm committing. I thought this was a pretty well used flow, but apparently it's not.

honestoHeminway 7y ago
A snake only encounters birds frozzen in fear
u801e 7y ago
I tell people to run git log -p --reverse origin/master.. and git diff origin/master.. to see what changes their commits are introducing and the overall change they're making before they actually push the branch up to the remote. It's essentially proofreading what you're going to submit before actually submitting it.
syncsynchalt 7y ago
Or better yet: `git add -p` If you only ever use `git add -N .` and `git add -p` you'll never have unexpected changes in your commit.
- cryptonector 7y ago
  Or better yet: `git add -e`.

BeetleB 7y ago

> And before anyone mistakes that for complexity on git's side… often, these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff. And yet I don't run into such behavior from people using SVN or mercurial.

plorkyeran 7y ago
Every SVN-using project I've touched has had countless examples of files accidentally being committed.