Suggestion: add chapters (timestamps) to this video. It really helps when you're watching for the second time!
The excitement level of this guy is priceless. Imagine working with him in a team!
Timestamps for dorks: 00:00 - Introduction 01:06 - About Me (well, Scott Chacon) 02:36 - How Well Do You Know Git? 05:09 - Our Agenda 06:25 - Some Helpful Config Stuff 09:42 - Oldies But Goodies 16:22 - Some New Stuff (You May Not Have Noticed) 23:48 - Some Big Repo Stuff / Monorepo Stuff 33:29 - Some New Github Stuff 35:54 - GitButler 36:50 - End of talk 37:03 - Start of Q&A Session 37:06 - Q: Why does GitHub not do git range diff? 38:28 - Q: Why do submodules suck everywhere? 40:16 - Q: With SSH signing, is it possible to specify more than one key? 40:42 - Q: Why can't --force-with-lease be the default force? 42:33 - Q: If you were back on the Git development team, what direction would you like to see it move in? 44:58 - Q: We all love the Git CLI - but do you ever use any visual tools? 46:41 - That's all folks!-
"fucking nerds...". Golden
Great talk, I really appreciate the "shotgun" style presentation - it cuts the crap while keeping it clear.
`git blame -C -C -C` is pure gold. But wait, there's more! From `GIT-BLAME(1)` -C[<num>] In addition to -M, detect lines moved or copied from other files that were modified in the same commit. This is useful when you reorganize your program and move code around across files. When this option is given twice, the command additionally looks for copies from other files in the commit that creates the file. When this option is given three times, the command additionally looks for copies from other files in any commit. <num> is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit. And the default value is 40. If there are more than one -C options given, the <num> argument of the last -C will take effect.
The talk is great, but the manner of it being presented is even better!
Thanks for the book. It saved my neck in 2011. Every intern I've had since 2012, on their first day, I give them the book and ask them to read it all, and do all the exercises. I give them paper so they can mark it up as needed. Every intern that does this, has no issues with git all summer. The one or two interns that did not do the exercises? They struggle. Great book!
Next to being an informative talk, the way it's presented is great. Good job on that presentation skills!
So excited to share this with my boss Mike, he's our local Git wizard and I'm so thankful for him. He's always so excited to share the new things he's learned and I'm looking forward to paying it forward!
10:59 that -L to blame and log is awesome!
If anyone has any questions or suggestions for the next version of this talk, we would love to hear them!
Time 8:13 - Setting or defining work and oss (open source software) directories. Thank you, Scott!
Didn't know that guy before, immediately caught fire because of his excitement, bought his book after the first 10 minutes. Great talk!
Really excellent talk. Incredible pacing, funny, and lots to learn for folks at every level.
46:30 I've been using Git for a long time and I use git gui for building my commit because I always commit lines of code, not full files. And I also use gitk for reviewing history of the code unless I'm looking for some highly specific thing that gitk doesn't support well – for those cases it's mostly `git log -p - - optional/path/limit` and grepping the results if needed. (The dashes should obviously be combined without a space but YouTube comment interface cannot display that string correctly.)
Scott Chacon is a legend! I learned git in 2016, and I love it, it's one of the most important tools for me, after start my journey as a developer, I start to teach git, and the best resource always was the Pro Git book.
I was there, great talk! Made me discover GirButler, super promising!!
committing to multiple branches is brilliant! its always a PITA to notice/fix a core bug when working on a feature branch.. stash->checkout->pop->commit->checkout->merge is so much overhead for what started as a 5-second one liner fix.
@NEDinACTION