Wrapping Up

[00:00:00]
>> I'm curious Prime's thoughts on large files slash LFS since it isn't covered in the content and any thoughts on squash merged, keep repos smaller.
>> Yeah, I don't care about the size. So there's two questions in there and they're kinda both the same. So get large files at the store is just like it's, it's it does some of efficiency.

[00:00:20]
So the thing that's happening if you didn't notice that we could go and restore every commit having every pointer to every file. Now, we can restore those files, those files were compressed and all that. So if you're storing like 100 megabyte image, it's gonna go and it's gonna compress this and then you have to download it.

[00:00:34]
There's a lot you have to download, so get a large file store just, Effectively is an optimization for larger Files, which are just a huge pain in the ass when it comes to Git. That's why people argue why Perforce is better, is actually specifically about large file storage and binary assets.

[00:00:49]
But now with Git, whatever it is, large file store LFS, it's better. As far as history size, I don't think you should really care about history size. History is free, right? I just like to have it clean, so when I'm doing a revert, I don't shoot myself in the foot.

[00:01:03]
I really don't wanna revert like a six item change with a bunch of merge commits. That's what I don't wanna do. I just wanna be able to just say, revert e and like that's it. So that's my only argument for why I prefer rebase over, it's cuz I inevitably bet against myself.

[00:01:21]
>> Outside of just some of the techniques you covered here for your own repo. Is there anything that you'd recommend for people who contribute as far as working with forks and just contributing to open source in general?
>> Contributing their open source?
>> Yeah, I think the question's more like, is there any techniques here that you use to, when you're working with your phone and pushing it back or submitting the PR back to some open source repo?

[00:01:49]
>> Yeah I think everything I already stated is exactly it. I try to do one commit, make it really nice. I try never, if I can, I try to never make a change ever above about 150 lines. There's some studies that suggest that people will rubber stamp significantly higher rates if you add more lines.

[00:02:05]
There just comes a point where you can no longer review well. So if you can keep things small and do more reviews, it just makes life a lot easier. So that's my only real thing is, if you're gonna be contributing to open source A, there's been a lot of angst over open source commits in the last few months.

[00:02:24]
So don't just make dumb commits. That's a good thing to do. Don't be mean, remember it's all free. No one's getting paid out there for open source. I mean, they might be getting paid like $20 a month, but that's not enough to really be happy with it.
>> And just to follow up to the env question, what's a good way to handle env files?

[00:02:46]
If you want everyone to have a base template, but make their own changes, do you add it to the repo? And then.
>> Yeah, you can add it to the repo with like a default one, save it, then ignore it. So then it's there, and no further changes can be had.

[00:03:03]
There's strategies, right? You can have the whole like env template or whatever, and env default and then you just copied over into yours. But that's all organizational stuff.
>> All right
>> I always do like env-something. By the way, great, also great plugin by the way. Great great great vim thing I don't know if you guys know about this but wait, hold on.

[00:03:26]
Chad stack that was using COBOL. If I go like this and by the way, if you guys don't know, you can get plugins so that if you have your env, it will automatically put little stars right there. If you ever accidentally don't want, you never want this thing leaked ever or for any reason, it's always good to have this thing on.

[00:03:42]
And so if you're in an env file, it'll just always do that. You can just do a little cloak doggle and boom, right there. And it's a fun little thing. If you don't have that, I always recommend having that. Cloak, I think it's named cloak for both VS Code and Vim.

[00:03:55]
It's a good little plug and a half. I just wanted to mention Vim more, if possible.
>> [LAUGH]
>> I'd love to talk to you about how your life can improve by using Vim. Is it possible to have a personal gitignore? Someone's asking that. There is, right before we go, there's actually a file inside of git that you can do.

[00:04:16]
So if I go like this here, I'll try to do this really quickly. I'll just go like this. I'll create a file like this, it's some sort of divorce hack file, right? So it's right here. It's this thing right here, get/info/exclude. So if you add it to the git/info/exclude, it's a gitignore but only for you.

[00:04:36]
So if I save this, it's It's gone, but nobody else gets it. It's one of those like super secret ones, but that's one of them. There you go. This is everything I think you need to know about, gets to be useful at your job. Everything else is, I don't think you need, just real facts.

[00:04:54]
There you go. That's it.
>> [APPLAUSE]
>> Thanks.