So You Think You Know Git Part 2 - DevWorld 2024
Vložit
- čas přidán 26. 06. 2024
- Scott Chacon's DevWorld 2024 talk on Git Tips and Tricks. Learn more at blog.gitbutler.com
Scott talks about:
00:00 Intro
00:33 Welcome
02:05 About Me
02:24 How Well Do you Know Git
03:19 Agenda
03:31 Switch and Restore
05:55 Hooks
08:33 Attributes
09:44 Smudge and Clean
10:08 Smudge and Clean: RCS Keywords
10:42 Smudge and Clean: Date
11:14 Smudge and Clean: LFS
12:25 Fixup Commits
15:41 Rebasing Stacks
17:58 Update Refs by Default
18:15 Scaling Git: Scalar
19:53 Worktrees
21:23 GitButler
22:43 Close
Didn’t know Pedro Pascal is such a git nerd.
Amazing talk btw!!
😂
It's not every day you learn several new git features to try out. Thanks for a great talk.
thanks for watching!
The best kinda days
I've used fixup commits and rebasing for many years. Can't see how you'd get a clean, meaningful history without it.
Lovely talk as always!
17:13 I am apparently one of the "three guys". I wished for this option for a long time. This is a huge lifesaver.
Agree, super useful.
Came here to say this! `--update-refs` where have you been all my life!
I love it! ❤
Yoo I was really excited by the first talk, so great to see the part 2 :)
Some reason I'm watching this part 2 :D !!
Presentation so fire you triggered the alarms haha. Loved both of these and I could listen/use many more :D
great talk and great speaker!
had a thought around 5:11: I understand Linus' concept of not breaking backwards compatibility, so that `checkout` will continue to work even though there are newer commands that do the same thing, but if the idea is to have these new commands be "more semantic" than the old ones, why not at least show a message in terminal when using the old command to say "hey, there's a better way to do this now"...? surely that would help people who use Git every day (like me) to learn them more quickly.
It's the best video I’ve watched the whole week. Thank you!
Dude these talks are so useful!!
Aside from the large repository stuff (scalar) I would have put my hand up for each question, and that makes me happy 😊 Great talk Scott!
Hey Scott,
I was barely able to get 50% of part 1 (some super heavy stuff for beginners) but this part was like you created this one for us only 🙌 the way you present these talks is just awesome 😂 please continue this series and let’s see a demo of gitbutler in the next part of this series and how’s about continuing this series until we don’t cover all 145 commands 😅😂
great idea to not repeat the talk 👍
Damn, I would have appreciated knowing about worktrees about 2 weeks ago 🙃
Always a chance to learn something new
i love these talks
thanks!
I had no clue you don't need to do an interactive rebase to make autosquash work anymore... Nice to know :)
I believe this was _very_ recently added. 2.44 I think, so maybe a month ago?
Great presentation style! 👍🔀🚀
Pretty glad I subscribed to the youtube channel :3
We're glad you did too! We'll try to make it worth your while. Let us know what you might like to see.
The most important thing to know about git : it is not a backup system, it is a collaboration system. You have to actually use backups with another software such as beyond compare, to reduce the risk of a bug in git that deletes files and folders.
Sometimes you don't have 5 hours to become an expert at git and understand why it suddenly refused to save the modifications. The slightest mistake, misunderstanding, or misuse of a command can harshly punish you.
No need to become an expert - you only need to understand the fundamentals to be able to work confidently with Git. Watch Chacon's original introduction in order to really grok Git, and you'll find that it's quite difficult to get it to lose your data. Just set a branch before doing something tricky. If you also push that branch to some remote, it's virtually impossible to lose your stuff.
It’s version control, first and foremost. I have plenty of repos where I’m the only developer.
I agree that it’s not a backup solution, i.e . if your disk is corrupted and you haven’t pushed your commits, you might lose data. However, as long as your file system is intact and you committed your change, basically anything “lost” can be recovered via git reflog.
`--update-refs` is great!
If I had your public speaking skills I would be between 2x and 500x wealthier. Well done talk.
nice intro)
worktrees are awesome
you didn't mention lefthook when talking about precommit and husky!!
Now onwards I will only use more domain specific/ explanatory commands instead of checkout I.e, switch and restore and allowing commit specific updates is also cool and yeah the best of all for jumbo repos I.e, scalar (any specific reason for not using git specific naming like git clone-heavy) 😂😎 I am feeling like if scalar might have introduced earlier then maybe pinterest never specify the refspec to reduce their clone time 🤪
The "restore" command semantically often makes less sense for me. I frequently check out changes I have never seen, stemming from other branches or even remotes, so it is definitely not restoring anything. So in many cases it fits, just "checkout" is more general.
Deeeespaaacito
Man they really skirted the copyright with that 😂 cool how they turned it into a beat though.
Those YAML configurable hooks looks nice, can these be globalized? I didn't get it to work.
With the attributes, that's a nice feature. I configured it so that in addition to calling exiftool, it also adds the hash (by making a script). This way you can see that it changed despite no change in exif data. You can also make it so git diff fires up the different pictures visually side by side, if you want to.
Scotch Cone.
GitButler looks really cool and very helpful, but unfortunately switching to a GUI client would change my workflow too much so I have to stick with either using worktrees or straight up separate directories for different branches.
Why is Scott against a rebasing flow?
When working in JetBrains IDEs, I use Change lists: for example, I can create one for dev changes (that I definitely don't want to commit), other ones per branch. When commit, I select only needed change list(s) and other changes are not affected. Overall, JetBrains commit tab is quite comfortable for me.
Across the talks there have been several recommended git config -global options recommended. Is there a good place to go to see an exhaustive list of recommended configs based on new feature adds or even just a merge commit’s expert opinion on recommended config?
You can just read the git config man page.
@@markusklyver6277 recommendation (n): a suggestion or proposal as to the best course of action, especially one put forward by an authoritative body.
@@markusklyver6277 The man page for git config sucks for this (or at least it used to suck). It's huge and some of the more obscure options are documented extremely poorly (or even not documented at all).
I was scared during the first few seconds of the video. Thought I was lost
it caught me off guard
I didn't see much in this talk that seemed of interest for me to look in to. I can see worktrees being useful. I already have multiple branches of a project checked out in to different directories but git doesn't know about the collection of directories. Using worktrees I can make it aware of the other branches being worked on.
Same here, I have like 5 different directories called git-1, git-2... I will try tomorrow
_ICT🌌1AM March 26th 2024_
Update refs❤❤❤❤❤❤❤❤😂
Yeah, renase with references on top would be damn useful 2 years ago for me =)Now I just try not to use that approach
and yet, -q and --quiet still don't work consistently
Damn, coming at you with commit hooks 😢😢. Really bad stuff
Nope. I don’t think that! 😂
almost nobody used autofixup? Wth, I'll do you one better, start using git-absorb
hi 🎉?
hi
Nobody knows Git
OhNo, there's more 🫣