Great video. I think another important detail is that if the author requests changes to your pull request, you can actually go back and update your branch, and the pull request will automatically include your updated changes (in other words, no need to re-open another PR).
Indeed. Note also that piling updates can make the history of your branch a bit messy. In such a case, I generally ask the maintainers whether they would like me to rewrite the history (git rebase -i). Some maintainers appreciate the clean-up, while others prefer to preserve the true history, that's why it's better to ask.
You can click on the filename:123 in the VSCode terminal to get to that line at once. And it's very convenient to work with changes (add files to commit, check what to add etc) in git tab in VSCode
2:36 yeah, that's why i like the gitlab's "merge request" term much much better. it's self defining what an MR would do, no push-pulling around with terms lol
To keep a file open in VS Code, you can double click its tab (or file in the sidebar). You can also ctrl+click the "path/filename:line:col" in the error log and VS Code will open that file to that location for you.
3:20 one suggestion while doing command/text interface stuff, please zoom in/increase the font size a little bit. as small font size requires watching in high res, which is punishing for people on limited bandwidth. 😇
7:53 one suggestion for commit messages, say "fix ..." instead of "fixed ..." it's not my advice, it's based off of some article, ig it was titled "how to write commit messages" or smth like that
Here is my experience with contributing to Open Source projects: 1- You need to have a very good understanding of the repository you are contributing to. This is why you're much less likely to succeed if you go in with the mindset "I want to contribute to open source" instead of "This open source tool that I use often and know has an issue, maybe I can fix that". So don't expect to fix an issue within a repository that you barely know. 2- You need to understand the field that a repo belongs to. It's unlikely that you will contribute to an operating system if you don't have a solid background in operating systems. I believe that open source contribution is a little overrated. There are other ways to show your experience other than contributing.
Thanks for your perspective. I really need to get over that "I want to contribute to open source" mindset. This keeps happening because I am not able to find any solid project to work on. Every hobby project that I start working on stalls halfway due to some reason. Requires a lot of discipline.
Shame that most of the things I want to fix require major understanding of how the project works so they're not trivial tasks. Damn I wish I could just work on open source software 8 hours a day instead of my job.
yeah i was lucky i found something that was easier to comprehend. i was playing world of warcraft and one addon i used was kind of annoying bcs there was some data missing. So i looked it up, learned the basics of Lua and then contributed a couple of times. You really have to think about everything you're using. Maybe there is a little tool that is easy to comprehend 👍
Many projects use labels to organize their issues and most of them use the label "good first issue". This means that it should be a rather easy fix like the one in the video and can be understood as some kind of invitation for new volunteers to participate. Of course most of them are not breaking changes but still things that need to be done and it heps getting started with a new code base you are unfamiliar with.
Generally, I noticed the following problems: I use repository fast-classpath-scanner, but then I noticed some problems, since an original developer was busy, I forked it, fixed problems and continued using. Late, I did a pull request, the owner agreed, and accepted it. So far, so good. But later, the author did some extension, changed API and I reminded using my fork. Why? I didn't need new features, and say more, I didn't want to continuously change my code accordingly the product changes. But, since new versions of Java were available, I need to do changers in the implementation, I started doing myself, but then just borrowed changes from the original projects. Conclusion: fork instead of pull requests, because you may have different view on a product change, but borrow some useful changes in it time to time.
They should have a CI runner for building the MacOS version, but maybe that's hard if it's specific to hardware. Definitely seems like something that shouldn't be too difficult tho.
Why is ‘git checkout’ the command to change branch? To checkout means to look-at but not touch, it’s really confusing terminology. Is there an extensible but more user-friendly and intuitive interface to use git with?
Most IDEs have some form of git integration, which allows you to use git with a GUI instead of the terminal. Most of them aren't very exstensive, but 99% of the time they do what is needed.
Git also features the command `git switch` to switch to branches/commits! It was introduced later, so `git checkout` can still be used to switch branches (for backwards-compatibility).
Great video. I think another important detail is that if the author requests changes to your pull request, you can actually go back and update your branch, and the pull request will automatically include your updated changes (in other words, no need to re-open another PR).
Ah, good point. Thanks.
Indeed. Note also that piling updates can make the history of your branch a bit messy. In such a case, I generally ask the maintainers whether they would like me to rewrite the history (git rebase -i). Some maintainers appreciate the clean-up, while others prefer to preserve the true history, that's why it's better to ask.
You can click on the filename:123 in the VSCode terminal to get to that line at once. And it's very convenient to work with changes (add files to commit, check what to add etc) in git tab in VSCode
2:36 yeah, that's why i like the gitlab's "merge request" term much much better. it's self defining what an MR would do, no push-pulling around with terms lol
Very helpful! Not only the pull request, but also seeing you create the fix branch, and push it back in with origin.
To keep a file open in VS Code, you can double click its tab (or file in the sidebar). You can also ctrl+click the "path/filename:line:col" in the error log and VS Code will open that file to that location for you.
3:20 one suggestion while doing command/text interface stuff, please zoom in/increase the font size a little bit. as small font size requires watching in high res, which is punishing for people on limited bandwidth. 😇
I was just looking for this topic in Google. Lol what a nice coincidence 🤔
Got notification lol
7:53 one suggestion for commit messages, say "fix ..." instead of "fixed ..."
it's not my advice, it's based off of some article, ig it was titled "how to write commit messages" or smth like that
Here is my experience with contributing to Open Source projects:
1- You need to have a very good understanding of the repository you are contributing to. This is why you're much less likely to succeed if you go in with the mindset "I want to contribute to open source" instead of "This open source tool that I use often and know has an issue, maybe I can fix that".
So don't expect to fix an issue within a repository that you barely know.
2- You need to understand the field that a repo belongs to. It's unlikely that you will contribute to an operating system if you don't have a solid background in operating systems.
I believe that open source contribution is a little overrated. There are other ways to show your experience other than contributing.
Thanks for your perspective. I really need to get over that "I want to contribute to open source" mindset. This keeps happening because I am not able to find any solid project to work on. Every hobby project that I start working on stalls halfway due to some reason. Requires a lot of discipline.
Shame that most of the things I want to fix require major understanding of how the project works so they're not trivial tasks. Damn I wish I could just work on open source software 8 hours a day instead of my job.
yeah i was lucky i found something that was easier to comprehend.
i was playing world of warcraft and one addon i used was kind of annoying bcs there was some data missing.
So i looked it up, learned the basics of Lua and then contributed a couple of times.
You really have to think about everything you're using. Maybe there is a little tool that is easy to comprehend 👍
Many projects use labels to organize their issues and most of them use the label "good first issue". This means that it should be a rather easy fix like the one in the video and can be understood as some kind of invitation for new volunteers to participate. Of course most of them are not breaking changes but still things that need to be done and it heps getting started with a new code base you are unfamiliar with.
Great example. Thanks.
Thanks for the video. Any recommendations on currently available opensource projects on Embedded Systems?
Generally, I noticed the following problems: I use repository fast-classpath-scanner, but then I noticed some problems, since an original developer was busy, I forked it, fixed problems and continued using. Late, I did a pull request, the owner agreed, and accepted it. So far, so good. But later, the author did some extension, changed API and I reminded using my fork. Why? I didn't need new features, and say more, I didn't want to continuously change my code accordingly the product changes. But, since new versions of Java were available, I need to do changers in the implementation, I started doing myself, but then just borrowed changes from the original projects. Conclusion: fork instead of pull requests, because you may have different view on a product change, but borrow some useful changes in it time to time.
I have a quick question, but whenever someone makes a change to the code would contributers have to refork to stay updated?
Thanks Jacob!
Get well soon, love your videos 💯
thanks. I'm well. I recorded this video a few weeks ago. So, I'm now feeling great.
What about beginners?
Instead of right-click -> keep open,
you can simply double-click the tab.
What about Sourceforge? Is it OK?
They should have a CI runner for building the MacOS version, but maybe that's hard if it's specific to hardware. Definitely seems like something that shouldn't be too difficult tho.
Jacob, I hope you get well soon
Thanks, Bhaswar. This was recorded a few weeks ago. I'm feeling much better.
Can you please teach how to build an OS from scratch?
Why is ‘git checkout’ the command to change branch? To checkout means to look-at but not touch, it’s really confusing terminology. Is there an extensible but more user-friendly and intuitive interface to use git with?
Most IDEs have some form of git integration, which allows you to use git with a GUI instead of the terminal. Most of them aren't very exstensive, but 99% of the time they do what is needed.
Git also features the command `git switch` to switch to branches/commits! It was introduced later, so `git checkout` can still be used to switch branches (for backwards-compatibility).
Love the content, Jacob!
Thanks.
If he rejects the pull request, you can always de-friend him in facebook.
😂 No worries. He accepted it.
3:12 "At some point I'm going to 'git' to it. :-) -- I see what you did there. :-)
🤔😀
great video
so many arguments to pass to function...maybe it could be better to pass pointer to some device context structure?
3:11 At some point I’m going to “git” to it ;)
Did you know that you can hit the '.' (dot) key, and Github will open a builtin editor?!
Just editor though. You can't run code as there isn't a server doing that for you. But still useful!
What about a video on mailing lists lol
They should have probably turn the 'rf2500_open' function into a variadic function when they change the api instead of breaking it...
looks like im early