here's a bug, here's something weird, or sometimes it's a, how do I do this? A pull request is, I've identified something for improvement, a bug or a feature, and I've attached code to that that can be merged in with the project. That's the difference. So, why don't we go through some of these together? Maybe not all, but let's see what we can get through in a reasonable amount of time. All right, here we have another one from Wilbur. Redirect to the threads route after login or register. So, currently, after a User logs in or registers, they are redirected to the home route. All right, let's see what he means here. So, I'm going to go to council.dev, log in. Now, I originally kept it this way because I thought maybe we would have a User dashboard, and we still might do that for a forum. You sign in, maybe you see a quick smattering of all the threads you've contributed to, maybe notifications and stuff like that. But at least

So, what should we do here? It honestly doesn't make too much difference. Like, you can set your local URL to anything that you want here. Now, I happen to use Laravel Valet, which, if you're not familiar with it, it basically allows you to throw a folder into your main code directory. And that folder is now instantly available as the folder name. And it originally was .dev. But I do know because of this issue related to Chrome, I think they now default to .test. And I just haven't updated yet. So, I could update. Or you can also say valet domain test. And that means rather than counsel.dev, I will visit counsel.test. But yeah, if you install Valet from scratch, I think .test should now be the default. Okay. So, let's give it a shot. I can now go to counsel.test. And there we go. Now it is working. Okay. So, that's fair. If it is the default, then we will update that like so. All right. So,

Okay. So, let's give it a shot. I can now go to counsel.test. And there we go. Now it is working. Okay. So, that's fair. If it is the default, then we will update that like so. All right. So, in this case, we have an issue where an issue exists, but there is no associated pull request. So, I'm going to fix the issue myself and then close it. All right. So, let's go to code. We will update environment.example. And this will be counsel.test as well. Let's switch to GitHub. We can see our change, use.test top-level domain. Okay. Now, once again, I want to mark that I have resolved this particular issue. So, it's number four, or you can always grab it from the URL. So, we will say resolve or closes or fix, any of those are going to work. All right. Let's sync or git push that up to GitHub. And now, if we give this a refresh, or it should happen automatically, there we go. So, now anyone interested can see,

All right. Let's sync or git push that up to GitHub. And now, if we give this a refresh, or it should happen automatically, there we go. So, now anyone interested can see, okay, Jeffrey added a commit to update this, and we're all set to go. However, actually, you know what? I think, do we have any reference? Yeah, see, this kind of sucks, and this is the downside of images. I will have to fix that separately, but I do want to update to this. Okay. So, sometimes you'll have this where you make a change, you push it up to GitHub, and you immediately think, oh, crap, I forgot to do that one thing. So, generally, you want to be a little careful, but in these cases, if you don't have other team members immediately pulling down your changes, you should be able to quickly amend your last commit. Just be a little careful about this if you're working on a large team. Okay. So, I need to open our README, and let's look for

to add this flag, git commit --amend. So, I want to amend the previous commit, and here you can see the previous commit. So, yeah, we're just saying add this change to the last one, all right, and we'll push that up. But it doesn't work, and that makes sense. The current commit is different than the one we have up on GitHub. So, we're going to say, yeah, I'm going to do a force push. So, I demand that you accept the shape that my current commit is in. Okay. So, now if we come back, let's just go to the home page, you'll see right here my commit, and yes, we updated that, but it now also includes the change to the README file. So, again, if it's something you've just done immediately and you have to do a quick fix, git commit --amend is useful. If it's like days later that you discover it, just create a brand new commit. Don't use amend. Okay. Maybe we have time for, let's see what we have here in pull requests, maybe one more. Default seeders instead of tinkering. Okay. This seeder will generate

brand new commit. Don't use amend. Okay. Maybe we have time for, let's see what we have here in pull requests, maybe one more. Default seeders instead of tinkering. Okay. This seeder will generate standard John Doe account and fake channels. Okay. So, if you're working locally, it can be useful to quickly seed up some dummy data here. I think there's an issue to go along with it. Yeah. All right. So, we think that it's much easier to execute php artisan db:seed instead of tinkering and generating. Yeah. So, often in the form series, if I quickly wanted to whip up a bunch of threads, I would say factory app\Thread::create, and maybe specifically I want 50 of them, right? You can also use a database seeder class to sort of formalize how you seed your local database. Okay. So, we have a PR15, and let's see what we have here. Now, in some cases, you can review the code directly on GitHub and approve it. In other cases, you really need to pull it down,

Okay. So, we have a PR15, and let's see what we have here. Now, in some cases, you can review the code directly on GitHub and approve it. In other cases, you really need to pull it down, test it if there are tests, or at the very least, run it through yourself to make sure that it does exactly what the user says. Often, you'll get a PR that says it does one thing, and then you maybe merge it on faith, or at the very least, at some point, you try it and you realize, oh, this doesn't work at all, and there's a big error here. How did they not know that? And that's just how it goes. So, as the maintainer of the project, yeah, the buck stops with you. You are responsible at the end of the day for making sure this stuff works. So, let's take a look here. He has, or they have, a sample data seeder. So, they disable any kind of weird foreign key constraints if you reset the database. And then, okay, two methods, clear out the channels table,

not through the acceptance of a PR, but yourself. You're the maintainer. You're going to add a new feature, write tests for it, and merge it into the code base.