6 ms·

> It's honestly crazy how much time we as a community of software developers spend thinking about Git. It's funny, I can't remember the last time I had to give

> It's honestly crazy how much time we as a community of software developers spend thinking about Git. It's funny, I can't remember the last time I had to give serious thought about how to use git. Sure, there's a learning curve. When I was just starting out, I didn't get it all right away. But it's been years since I've thought much about branching strategies and stuff. And I don't get myself into "terrible messes" that take hard thought to get out of. Not saying you're 100% wrong. But it doesn't line up with my experience.

andrewstuart2 7y ago
What rings truer to me is that it's crazy how often building a tool or process, etc, eventually turns into people being able to make careers of just that thing because of all the spins and metaprocesses people will throw on top of or into it. Git springs to mind for one, but (capital A) Agile definitely wins the championship.
- james_s_tayler 7y ago
  Most teams or companies I've worked in have a git guru but it's far from all they do. It's the occasional stop by at that person's every so often for help with something that is outside the absolute basics.
- projektfu 7y ago
  Sometimes it’s just that by taking enough out, it becomes unclear and complicated. I “taught” eXtreme Programming to two of my own teams by showing them the book. Worked like a charm. I also participated in several “Agile” installs that failed despite training, meetings, demonstrations, etc. All because removing the “customer is in charge and developer is allowed to get the job done as they see fit” component made it complicated.
kochthesecond 7y ago
I am with you on this. Its been years since I had an issue with git, and branching strategies are not that hard. In smaller teams most solution that show up are also usable. I would argue git is actually a fantastic tool that gives immense value year after year for no cost compared to any other alternative. There is a learning curve though.
Supermancho 7y ago
If you've never had a git commit FAIL (eg https://github.com/okonet/lint-staged/issues/565 https://github.com/okonet/lint-staged/issues/565) you aren't very experienced with git. By your description, you've probably just used it casually a lot. You don't do anything complicated and conclude that git isn't complicated. Given the history of working with: * Submodules * Binaries * Large Repositories/branches * A disparate set of development platforms/clients * Git auth/credentials
- eropple 7y ago
  The largest git repo I touch has half a dozen submodules (some with their own, you have to do a recursive clone), about two thousand branches (historically, we prune them) and about two hundred thousand commits, and has committers on Windows, Mac, and Linux. It doesn't have binaries in it, 'cause git-lfs. But I don't remember the last time I had a problem with it other than PEBKAC rebases and the like.
- reificator 7y ago
  > * Submodules > * Binaries > * Large Repositories/branches > * A disparate set of development platforms/clients > * Git auth/credentials I have experience with all of these things and have not had a commit fail.
- bananabreakfast 7y ago
  lol, gatekeep much?
  - Supermancho 7y ago
    He asked why people spend so much time trying to work with git abstractions then claimed "works for me". It's not gatekeeping, when replying to strawmen. Try to keep track.
    - jshevek 7y ago
      I don't think you are applying the principle of charity when reading his words.
deathanatos 7y ago
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.
stephen_g 7y ago
While I spend a bit of time fixing other people's messes, I have to agree. I find the biggest issues are people who don't really understand Git enough doing silly things, or just being careless. Like somebody cherry-picking something to Master and then cherry-picking it to a branch we're working on, but on top of some stuff that has changed in that branch, requiring them to fix a merge conflict. But then when it comes to rebasing the branch on Master to merge it, you then have two more conflicts to deal with that you didn't need to have, if it had just gone once to the right place! It's not hard to fix, but annoying, and you risk introducing errors to the code if you accidentally miss a line or something. So the biggest issues are probably 1) people not following our workflow, creating extra work to fix, 2) people not understanding Git enough; or possibly for some people, 3) you team/company's git workflow isn't very good. In most teams for 3 (which is probably one of the more common ones), you really only need one or two people who really understand Git well to set up the workflow and enforce it.

andrewstuart2 7y ago

What rings truer to me is that it's crazy how often building a tool or process, etc, eventually turns into people being able to make careers of just that thing because of all the spins and metaprocesses people will throw on top of or into it. Git springs to mind for one, but (capital A) Agile definitely wins the championship.

james_s_tayler 7y ago
Most teams or companies I've worked in have a git guru but it's far from all they do. It's the occasional stop by at that person's every so often for help with something that is outside the absolute basics.
projektfu 7y ago
Sometimes it’s just that by taking enough out, it becomes unclear and complicated. I “taught” eXtreme Programming to two of my own teams by showing them the book. Worked like a charm. I also participated in several “Agile” installs that failed despite training, meetings, demonstrations, etc. All because removing the “customer is in charge and developer is allowed to get the job done as they see fit” component made it complicated.

kochthesecond 7y ago

I am with you on this. Its been years since I had an issue with git, and branching strategies are not that hard. In smaller teams most solution that show up are also usable. I would argue git is actually a fantastic tool that gives immense value year after year for no cost compared to any other alternative. There is a learning curve though.

Supermancho 7y ago

If you've never had a git commit FAIL (eg https://github.com/okonet/lint-staged/issues/565 https://github.com/okonet/lint-staged/issues/565) you aren't very experienced with git. By your description, you've probably just used it casually a lot. You don't do anything complicated and conclude that git isn't complicated. Given the history of working with: * Submodules * Binaries * Large Repositories/branches * A disparate set of development platforms/clients * Git auth/credentials

eropple 7y ago
The largest git repo I touch has half a dozen submodules (some with their own, you have to do a recursive clone), about two thousand branches (historically, we prune them) and about two hundred thousand commits, and has committers on Windows, Mac, and Linux. It doesn't have binaries in it, 'cause git-lfs. But I don't remember the last time I had a problem with it other than PEBKAC rebases and the like.
reificator 7y ago
> * Submodules > * Binaries > * Large Repositories/branches > * A disparate set of development platforms/clients > * Git auth/credentials I have experience with all of these things and have not had a commit fail.
bananabreakfast 7y ago
lol, gatekeep much?
- Supermancho 7y ago
  He asked why people spend so much time trying to work with git abstractions then claimed "works for me". It's not gatekeeping, when replying to strawmen. Try to keep track.
  - jshevek 7y ago
    I don't think you are applying the principle of charity when reading his words.

deathanatos 7y ago

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.

stephen_g 7y ago

While I spend a bit of time fixing other people's messes, I have to agree. I find the biggest issues are people who don't really understand Git enough doing silly things, or just being careless. Like somebody cherry-picking something to Master and then cherry-picking it to a branch we're working on, but on top of some stuff that has changed in that branch, requiring them to fix a merge conflict. But then when it comes to rebasing the branch on Master to merge it, you then have two more conflicts to deal with that you didn't need to have, if it had just gone once to the right place! It's not hard to fix, but annoying, and you risk introducing errors to the code if you accidentally miss a line or something. So the biggest issues are probably 1) people not following our workflow, creating extra work to fix, 2) people not understanding Git enough; or possibly for some people, 3) you team/company's git workflow isn't very good. In most teams for 3 (which is probably one of the more common ones), you really only need one or two people who really understand Git well to set up the workflow and enforce it.