That being said, how do you feel about using this technique for repos with 2k+ commits? It seems unrealistic to read all of them, or am I being short-sighted here? I get demotivated just thinking about it.
Forcing yourself to read every commit to a project you "like" in order contribute to it is putting the cart before the horse. Just because you "like" a project doesn't mean you will have the skills to contribute usefully to it. This isn't a bad thing. I "like" GCC, but I don't have the skills to contribute to it. I'm not losing any sleep over this, and I'm definitely not thinking about reading every commit to GCC in chronological order.
If you use a project, you might find a bug or some deficiency in it. Then it might happen that you have the skills to quickly fix this problem. Either that, or this bug causes you so many problems or slows you down so much that it becomes worth it for you to develop the skills to fix the problem.
Thanks for the answer.
But I love it and it is great recommendation.
Going to move with commits to see how it unfolds :)
I'd recommend OpenBSD libc. https://github.com/openbsd/src/tree/master/lib/libc
String functions especially are a good way to get into the C way of thinking. Since C's approach to strings is unique.
I also learned a lot by reading manpages of libc functions or Unix utilities and thinking about how they were implemented, and writing my own little versions.
git log -–reverseIt is NOT for learning the codebase.
It is for learning how to program in C.
Redis is a great piece of software because of how much it impacted the "evolution" of Internet not because of the code quality, Redis's code resemble spaghetti code, a lot.
I will push myself and say that nowadays people would get fired for writing code like that!
And before someone start to throw stones (just for the sake of it), here a few examples: - Redis source code is FULL of GIANT files with thousands and thousands of lines of code, decoupling and separation of concerns are basic things! A few examples -- https://github.com/redis/redis/blob/unstable/src/module.c -- https://github.com/redis/redis/blob/unstable/src/cluster.c -- https://github.com/redis/redis/blob/unstable/src/redis-cli.c -- https://github.com/redis/redis/blob/unstable/src/networking....
- talking about auto generated, the repo contains commited auto generated code, a valid reason though really slips my mind (yes, of course I can think of a few, but ... really? :)))
- https://github.com/redis/redis/blob/9c7c6924a019b902996fc4b6... ... that struct feels like an "Italian minestrone", basically a kind of soup where you throw in, literally, all the vegetables you have around and it's great for a soup, a bit less for software engineering though :)
- the naming structure is a bit random at times, there is a mix of camel case, camel case mixed with underscores from time to time, pascal case
This kind of staff might be alright for a 0.3 or 0.4, maybe even for a 1.0, definitely not for a 7.x that has had 15 years to evolve :/ Even in cachegrand, that hasn't got to a v0.2 yet, I tried to avoid these kinda of dramas, in C is quick and easy to get there if you are not careful.
There are plenty of other small things but most of the big dramas should be there.
The fact that "can be done" doesn't necessarely mean that "it's the right way" to do it.
Going back to embedding auto-generated code, focusing on this specific case, are you telling me that a line in the requirements.txt, on a machine where the user is expected to have access to a compiler, is the reason to keep auto generated code in the repository? Sorry, personally it seems a flaky reason.
Also, the very fact that you mention that users don't have superuser privileges should be even more of a reason to use virtual environments, where you don't need super privileges, or if you can't or want to use virtual environments you can still have multiple paths in the PYTHONPATH env variable and you can install packages in a specific paths leveraging the --target of pip or the PYTHONUSERBASE env variable, solving the issue as well.
I would prefer to suggest my users to improve their runtime environment than enable them to improve the chaos.
Unfortunately, suggesting that users improve their runtime environment is frequently a nonstarter for different reasons. (One obvious reason: users either don't have time or technical experience to do so.)
Since you are already familiar with other languages, you obviously don't need to know the basics of C. The basics are the same everywhere. Instead, you'd likely want to build that mindset on how to build good software with C.
I suggest you read other people's code and try to deep dive into the whys.
I heard Redis is a well-written software.
We can now see the very first commit made by Salvatore Sanfilippo. From here, we can start exploring. By looking at the commit diffs and git log messages, you'll be able to understand the motivation behind the changes.When you read a book, the most interesting parts are usually after all the theory is explained at the beginning. Somewhere in the middle of the book they start showing you code samples and that's when things become really interesting.
What I like about the reverse git-log approach is that it immediately throws you into the middle section of the book. This approach is both fun and eye opening.
Good luck!