Before using git, I had a script that automatically zipped my current project on Windows startup. The zip file was named after the current day and time. I regularly uploaded those zip files to an FTP server (manually) and actually never lost any data by accident.

@salim444

24 күн бұрын

real question is, was it written in clojure ;)

@GDScriptDude

24 күн бұрын

I have been questioning why I use git for personal projects and recently set up an automated hourly (rsync) backup of my dev files to another disk on my computer. A missing feature is to have some historical backups to rewind changes.

@pookiepats

23 күн бұрын

@@GDScriptDude seems like you answered your own question

@ChrisAthanas

22 күн бұрын

Most developers rolled thier own backup routine before source control became popular. We were all forced to when we lost our work just once, maybe twice for a slow kid like me.

@AloisMahdal

21 күн бұрын

if you're using git as a backup tool, you're probably using the wrong backup tool. eg. borg backup would probably serve you much better

10:30 this frustrates the hell out of me, when it comes to Masters programs... I want to study computer science, yet the degrees want to insist that I learn software engineering patterns and cloud computing - likely to help pad the schools' job placement stats. When I asked if I could replace those courses with additional algo/compilter/OS/theory courses, they said "no" :/

@giorgos-4515

14 күн бұрын

I feel you so bad, my Uni added an enterprise software development Master's

5:25 I add files one by one while commiting. I have two reasons: 1. I code review my past self, check if i forgot something etc. 2. I formulate the commit message by going over the changes

@AloisMahdal

21 күн бұрын

my 3. I often sneak in smaller drive-by fixes like docstring lies or small refactoring -- so this is how i can split them into separate commits ..which I then might or might not throw away if i change my mind. so it's also a way to lower the barrier of making these quick fixes because i can now rely on myself reviewing and reconsidering them later without putting the main thing in danger by dumb things actually sneaking in via `git add .`

@masterchief1520

15 күн бұрын

Same

Hey Lane, I'm a new graduate who was feeling pretty dispirited the last few weeks while trying to find a job. Your videos have really helped motivate me and put me on the right path to enjoy making projects and doing some leetcode in the meantime. Thanks for all you do!

I had attended Prime's git session on frontend masters... And now I can say that I know git.. atleast I know the part of git that is often used in production, that part which most people fail to understand and perform big oopsies here and there.. thanks Prime❤️

It's crazy to me that trade schools seemingly aren't more prominent in the IT field in the USA. Where I live, they've been well regarded since well before I was born.

@ChrisAthanas

22 күн бұрын

The field moves too fast, but seems to be coming to a consolidation point. Also teaching CS is really hard.

@markkalsbeek5883

19 күн бұрын

​@@ChrisAthanas I'm not so sure about that. Here in NL kids are separated into tracks early high school. These lead to trade school, science education, and something in between. IT and programming education exists on all levels. The in between level, which I think is what prime is thinking about is a 4 year degree, but you get to leave highschool a year early compared to the university track.

@orbatos

17 күн бұрын

Look into brushing and communications classes in electrical unions, they are literally the trade schools you are referring to.

On the other hand when I've worked at places hiring fresh-out-of-college devs, the fact that the colleges teach a lot of useless information but couldn't even be bothered to expose students to git was infuriating. Because _consistently_ I'd have to spend 70% of their onboarding time walking them through "okay, first you have to git add, then- no you have to type git add- no you can't do a commit yet because you have to stage things first... Yeah git _is_ really useful I have _no idea_ why your teachers didn't tell you about it :eye-twitches:" These kids aren't even _at_ the starting line half the time.

@taragnor

2 күн бұрын

Yeah... there are certain tools every CS student should learn, and Git is one of them. Version control, debugging practices, and an example of a build system should be mandatory stuff you learn.

In my university, there's a mandatory software class for electrical engineering where students learn about linux programming and they also learn about git, valgrynd etc. This semester we started teaching devcontainers too, though only at a very basic level.

In Germany, we have the concept of a University of Applied Sciences. You will also be able to do a Bachelor's or Master's but the goal is not to prepare you for academia, it is to prepare you for a career in the field. And often, professors are actual practitioners who do the teaching on the side. The degree also includes projects where you help a company with some practical problem.

"git add -i" gives a helpful interactive loop, and even lets you drill down and choose specific diffs within files to include or exclude from the add.

Starting from 28:00 Is it not already possible to use squash commits on merge without using rebase? One only needs to resolve the merge conflicts once per merge into their feature branch. This points toward the norms around your team's contributions. If you're releasing with branches, developing branches off of other branches, maintaining a feature for a long time outside the main, rebase makes more sense. It's less necessary for trunk based development.

15:08 I went to a school that genuinely did exactly that - a two year course with a singular focus of preparing you for the workforce. The school board consists of hiring mangers. To be on the board the company must also hire interns from the school. Students in the same vain are required to complete an internship to graduate. The internship can be with any company related to the degree.

@larkohiya

4 күн бұрын

Said that way... It sounds depressing.

I recall first version control. Sources on 64MB USB drive, once in the week we met with friends, we compared our new files with "repository" copied them over. If two of us had files modified in last week, we manually checked for conflicts. Then maybe in 2003 or 2004 we started using tortoisesvn.

22:00 branch~1 would go back on the branch history. branch^1 would go back on the incoming merge history. Basically it chooses left or right path to trace back.

For the git in school, so far, whenever we have had team projects they would always tell you to use the school gitlab (for multiple reasons) (ok actually first year there was a full year project where they just said you can use whatever implementation of version control you want, which I didn't really like since they gave no info on what options you may want to pick and kinda just threw first years into the deep end, luckily I already knew git from using it personally and just told everyone how to use it, although we did some cursed stuff with it.) Anyway, we were directed on commands and a brief summary of different git flows and why you may use them and said that for that courses project you should try to implement a kinda github flow (it very much wasn't because they needed it to fit some marking schema, idk). It felt much better than the first year but a lot of the time just felt that there were still some stuff missing. But hey, schools are already doing some of the stuff Primeagen is saying, just maybe not enough.

15:00 In Canada, we have 2 and 3 year programs. Confusingly for most people, we refer to those as College. We refer to bachelors, masters, and PhD courses exclusively as University to differentiate it. The 2 and 3 year courses are essentially vocational training, with much more emphasis on the practical side of things. If you take a third year, there's a lot more of the theory there. A computer programming course for example wouldn't introduce DSA and such until year 3 if you chose to take the 3 year program. An example of the sort of classes in a college course would be like a couple courses on Java, several classes on web development (one class is just intro to HTML/CSS and SUPER basic JS, next class would be mostly JS focused, maybe using React or some other framework), Classes on networking, digital logic/boolean algebra, basic stats, some embedded dev on an arduino or similar device, etc. The classes are broad, basic, and heavily focused on practical experience. They're generally much easier than the University/academia stuff. They're not as laser focused as a bootcamp, so students get a much broader introduction to programming. The 2 year programs I would consider not a great choice, since they really leave out all the useful comp-sci stuff, but someone who is a motivated self-learner could make do with it and self-learn all the comp-sci they need later. Many colleges also have co-op programs where they require students to take (paid!) internships for a semester per year, ensuring that students get real-world experience before even graduating.

@euclid9492

22 күн бұрын

That actually sounds amazing. Teach practical job stuff first and then go conceptual once you know students can do some form of basic programming job. I got a Software Engineering bachelors in the US thinking it would be more practical than CS. Only took a single web dev course senior year and just got more math requirements than CS to get the coveted “engineering accreditation” and did way too much UML. I think we could learn from Canada here!

@Bobbias

22 күн бұрын

@@euclid9492 I forgot to mention, college here is significantly cheaper than university too.

The rule I have is rebase if you know how otherwise merge squash. Usually works out; if you really want to maintain your change history then you’d learn rebase by now, but most ppl don’t care they just want their code checked in.

I learned to not use "git add ." after adding 1000 meta file changes to a unity project during my first job. Also, another job had a build system that added unwanted local configs occasionally. So I think double checking isn't bad. Also, I also think going file by file helps remove any extra comments or unused code. Like a mini pr you do for your own code.

@marioprawirosudiro7301

4 күн бұрын

No, you can still use "git add .". Just have to put those meta files in ignore.

@jeremylakey680

3 күн бұрын

@@marioprawirosudiro7301 You can't just add them to a git ignore. Unity meta files sometimes need to be adjusted. Because they positioning and more game object values. I don't know what it was but something slightly adjusted every unity object in the scene after I saved. Sorry, but you not very convincing. We all make mistakes, and looking at you work before committing is probably going to help in the long run as a professional.

@marioprawirosudiro7301

3 күн бұрын

@@jeremylakey680 I know. This is one of the biggest reasons why I moved away from Unity. Back then my solution was to ONLY include the scripts, zip away the corresponding meta folder and share it on a file sharing site so my teammate can have the same ones, effectively treating the meta files as blobs (which tbh, it effectively is). We did this for every commit. It was tedious, but still better than dealing with the incessant messages because the meta files keep changing.

Can someone give the details on what it means when git ignore and git exclude are "clean" does that mean FULL of all the files you want to not commit or Empty of files that you don't want to commit AND you just add the files individually, but also I know how that isn't the only other option and both host and guest use git add .

I remember huffman encoding from my algorithms class back in 1995, when we had to write a c program that compressed a text file by using that exact prio-Q algorithm.

The 6:15 "If I don't add it to the git ignore I'll accidentally add it at some point" comment is so accurate, but it's also why I prefer to manually review the changes to my files. If my typical process is to manually review my changes, I can work as quickly and as sloppily as I want to, without accidentally committing something silly, because I forgot to add a special step in my workflow. If my typical workflow is to catch mistakes by carefully reviewing all my commits, then I always have a backup plan for making sure I'm not mixing up WIP features with emergency production bugfixes. Due to the large legacy corporate codebases I'm usually working with, it's always a good idea to review your changes and make sure nothing unrelated is going out. It's also ironic that you described college as "getting bitten" at 15:40, only to go out on your own and learn, because that's exactly what I did. Literally. I had made plans to attend computer classes in high school that had been ruined multiple times. I had been absorbing concepts through osmosis, patiently waiting until I finally could enter a real computer science class. Only to have the Dean walk into our college class half way through the semester to explain that our professor "had an emergency", and wouldn't be returning. The last minute backfill they found literally just read word-for-word from the power point slides for the rest of the semester. All the students were pretty upset with how things went down. I was so fed up with being unable to find a real teacher that I decided I'd just teach myself. I went out, read the entire book from cover-to-cover, did more than half the exercises in the book on my own time, and I also learned the basics of C++ enough to build a small game. It truly was my teaching myself everything I'd need to succeed as a software developer. Hearing Prime talk about schools vs bootcamps actually makes me want to see how I can contribute to boot.dev.

24:39 I’m in the never merge camp. The only acceptable exception to that is when doing semi-linear history like what GitLab supports. I’m also in the never squash camp.

i did not get the rerere part. i always rebase my branches. if there's a conflict with main branch, i have to resolve it but once i do that the commit is already irrelevant to sub-sequent rebases (after main moves again). why would there be need for this? i feel like if someone is running into same conflict again and again, they have to be doing something wrong -- am i wrong?

@TurtleKwitty

5 күн бұрын

It's just the way rebase works, it goes back over older commits to make sure that nothing snuck in so it can recompare to the same older commit that caused an issue multiple times; its not that the conflict happens multiple times it's that its reanalyzed multiple times so rerere tells it to just redo the same fix you did the first time when you reanalyze the same conflict (should be a default really but omission from the original version and linus refuses to ever change a default no matter how ridiculous the old default was)

Adding files individually is something I also don't understand, but I still don't just add everything. I love me some git add -p Interactively go through each bit that was changed and decide whether to add or not. This is great for double-checking your changes, make sure you didn't forget some debug prints, etc; and it also sometimes makes me realise that, actually, this should be two commits.

@Yotanido

24 күн бұрын

@@test-zg4hv git gui, lol

@joaopslins

24 күн бұрын

I recommend reading Git book, chapters 2, 3 and 7. It helps a lot if you want to understand it properly.

@AryadevChavali

24 күн бұрын

Use magit kek

19:20 I think that one null check 40 lines before is the correct way to go but it's sometimes good to have an assert() near the use site to trigger and error if somebody modifies the code above. The idea is that assert()s are active while developers are modifying the code but it's not needed to run in production version. And if developers are running with assert()s disabled, they should be shamed of themselves.

I'm with Prime here. Using git can be part of exercises (and seems to be pretty common atm in programming heavy courses like computer graphics where you write tons of C++). But they can figure that out themselves, you don't have to explicitly teach it. If you do then you should go really deep and on concepts that will stay with you when all technologies change in 4 years. Similarly learning specific web frameworks or languages should only be a vehicle to teach the underlying concepts. I've been programming for over 20 years now and it's the concepts that stayed. In school we did COBOL and wrote Snake in assembly, we wrote WinAPI and MFC stuff, worked with Borland C++ in DOS and NetBIOS. BTW that was at what you'd probably call a trade school. A school from age 14 to 19 where about 40% of the time is focused on applied education (we got them for everything from programming, electronics to mechanical engineering and woodworking). It was really good to get a job instantly. I still preferred CS at university after all because it then really taught me the foundations of what I've just been using before.

What if your job makes push and merge the only option?

9:40 that's how the free git book on the git website and the o reilly version goes about teaching git. really does help with learning git

Historical fact. In 1890, US universities copied the German model which focuses less on giving a universal education of ARTS and SCIENCES and more on finding which companies will pay the most to the school in order for the school to rain up researchers who run tests, which will return reports that make the businesses look good to increase profits to pay schools more.

14:23 I wish I could do that for the subfields of computing science "only"

My boss loves rebase, I hate it! It causes conflicts constantly! I prefer fetching changes from main, merging into my branch then creating my branch pull request. I get that rebasing might keep the tree a bit cleaner but I've NEVER had a conflict merging main into my branch, yet rebasing my branch on top of main causes issues 80% of the time.

@backendbanterfm

24 күн бұрын

rerere

@cottonman132

23 күн бұрын

I like rebasing too, but when I know I'm working with someone else on the same branch I always merge, saves you the trouble of having to worry about force pushing over someone else's changes

The most interesting thing about Git is that its implementation is surprisingly simple compared to how much it can accomphish.

Thought Prime was gonna lose me on his super spicy take, but he nailed it!

I agree with Primes take on this wholeheartedly. A surface level understanding of git does not really provide enough workflow benefit over manual tracking of small personal projects. A deeper understanding would inherently 1) make it easier and understand 2) faster to use and 3) allow for more access to the more complex benefits. Also a degree should emphasize the mechanism behind any tool since there is no guarantee that git will remain the de facto solution 30 years later.

For those who wondered who he was talking about "The man that knew everything" in the 1700s... @14:06 Samuel Taylor Coleridge & William Wordsworth

2:15 You could have also just run "git rebase --continue" after creating one or more extra commits. Git will accept that just fine because it specifically supports splitting commits when you "edit" a commit during a rebase. It may mess "git rerere" a bit but everything else will be just fine.

Berkeley EECS 61B teaches how to implement a Git client. We were already expected to know git use on our own.

We used to have 4 year bachelor equivalent trade schools here in the netherlands. But the introduction of the bachelor/master system is messing them up as they all want to be more academic. They were ok, but I still didn't get any courses on source control (git didn't exist yet).

TIL there are people that add files individually. Or merge instead of rebase.

My problem with rebase is that everyone suffers very immediately from a junior coworker’s skill issues

@backendbanterfm

23 күн бұрын

That's....fair

28:00 "Always bet against yourself". I totally agree. Always assume you've made a mistake you're not aware of and you'll need to fix the code two years into the future when you cannot even remember writing the problematic line. The code should be as simple as possible to be easy to debug and commit messages should explain *why* the line of code was written in the first place. Commit messages should not explain *how* the code was modified because automatically generated patch already contains that information. It's okay to *also* include summary of changes but it's not replacement for documenting why the code was modified. AI generated commit messages can only do the summary part at best.

BTW, couldn't agree more on teaching how to build it (git) and how the distributed algorithms work, how 3 way merge works, etc, etc... Once you know that, using the tool is easy, and you have the benefit of being able to build other systems that use those same ideas (just hopefully not blockchain stuff) :)

I've been using Git for 10+ years and if I use "git add ." or even "git add -u" that's a huge exception. I'm pretty much always using "git gui" to commit individual lines, not files. I'm basically doing myself a code review while I'm creating the commit and I'll typically catch a stupid typo or some other simple issue before even completing the commit in the first place. It also allows committing logical changes. For example, if I actually fixed one small bug in existing code and implemented a new feature, that should be two separate patches even if both happen to co-exist in my working directory. Basically make as small commits as possible but every commit should be able to be reverted as a single commit. If reverting that single commit makes no sense, then it shouldn't be a single commit. Commits should be atomic.

100% agree on teaching version control as part of CS, instead of any particular tool. In my course in 2006-2009, they made us use Tortoise SVN for one of the classes, which I hated the interface of and thought it was garbage, but without explaining version control much, therefore I thought version control was hard and sucky

Need to learn how and why the abstraction exists before learning the abstraction

I understand rebase is important, i dont know if I'm doing rebase wrong , but they are hard to do

Ok after watching Prime's explanation of why he likes rebasing, I understand all that part of it. The problem then comes when I'm spending 2.5 hrs manually resolving conflicts on every single commit I've made, many times the exact same resolution. I've recently learned you can use rerere but I haven't tried it yet. I'd love to never look at a conflict again and if I do it better just ask me once and move on! What am I doing wrong that's causing me to resolve conflicts over and over for every commit on my branch to get things in line with main?

@TurtleKwitty

5 күн бұрын

rerere is just a config toggle, there's not "using it" specifically. So if you're still in the "ive heard of it but havent tried it yet" just do it, this is your signal

We never had a course in CS specifically for git, we had like 2-4, 2 hour sessions that you could opt into, if you did not know git to get the basics down.

In my CS degree I was taught git in a single session just by going through a ton of commands, but without any explanations on how things actually work or even a demonstration. We were meant to use it for that module but it was so bad that nobody in the room understood it, and we all had to go learn on our own. That being said, I think it's a good thing to learn in school, because you will need it in practically any company you work in. I think being told everything about how it works could be good, but I disagree that there's no point teaching it unless you get told the full implementation. It's not like you get told how a compiler works before you start using it.

38:02 Brasil mentioned!

Chrome asks the server with "permessage-deflate" header on websockets... So it is supported in Chrome at least. It maybe only supported over https

29:20 would you not just push a revert commit??

The issue with this is that programming without a ruined education is very limiting. Existing vocational trade schools you are thinking of exist, but they are largely terrible at picking good subjects to teach and often hire incompetent people as instructors.

Add some "evil merges" in that Git training. Lol. Those are always fun.

Spot on with the trade school take. 2-4 year program with hands on building and learning in a tight loop. No todo apps nonsense, no unrelated classes, build real software a company would license or pay the students to build. Like welding and similar trades the graduates would ideally be ready to start a job and be useful on graduation day.

Unless I am misunderstanding, I think the part about revert is just wrong. It is trivial to revert that with one command. That command is just...revert. That's what git revert does to a merge commit. It's not even some arcane option - it's the default behavior. He makes it sound like he thinks that reverting the feature->main merge will also revert the commits from the main->feature merges, as if you'd have to dig into it and sort the feature commits from the mainline commits that you brought into your branch while you were developing, but you don't - that's the default behavior of git revert. Unless I am misunderstanding, this is a completely wild mistake for someone selling a git course.

15:30 sounds like prime talking about a vocational training system. In Germany nobody has to go to a university to become a software developer, you just do a paid, dual (on-site at a company aa well as on-site at a vocational school) apprenticeship as a software developer for three years.

why would rebase or not be a question what

You know it's interesting about how AI services and things are shifting academia into a newer direction that I think is like how was described as an older, more ephemeral style of grading that required participation in the group. Because homework and reports and stuff like that are basically toast. idk

27:25 Yes, rebase feature branches unless you have a really good reason to do a merge. No, don't do squash merges unless your separate merges are true hot crap. Keeping historical commits as separate with individual commit messages help you in the future when you have to maintain the code as legacy code and nobody can remember why the code is written as it currently appears. When you have well written history for a project, running "git blame" will result in annotating every line of commit with an *explanation* why that line of code does exist. And that explanation should better be something else but "random commit of my workspace" or "squash commit of half-a-year worth of work for feature X".

My daughter was in a hackathon at 14 years old, where I witnessed a bunch of children learning Git; on a random mix of Windows and MacOS. Git has to be taught in school. Because teachers without it will give you assignments full of bugs. My daughter actually quit high-school computer science because of all of the drudgery of just catching up to debugged code. High school and college absolutely must teach basic Git as a prerequisite. I think CS professors saying that "teaching git is not my job!" are total idiots. It's a prerequisite to any class where the teacher needs to disseminate code. The teacher ALWAYS has bugs; that get mixed in with student bugs.

@ar_xiv

8 күн бұрын

Or you know… tell them to download the zip lol

@robfielding8566

8 күн бұрын

@@ar_xiv that's exactly what the problem is. most of the kids download the zip. they can't get the example to work. the teacher has YET ANOTHER bug; almost every other project. if teacher keeps putting out new versions, it's chaos when the patches come in over the buggy code that the kids are writing. Rather than.... teacher diffs to see what the kids did, and merging the teacher's bug fixes. "just send zips around", or "just put code in a directory" is why git was created in the first place; to stop that madness of multiple editors on the same archive.

@ryanfeeley2407

3 күн бұрын

I feel this. No so much that they need to teach git, but that requiring the subject will force teachers to learn it, and thus improve the deployment of their assignments. That makes sense. Assignments of complexity can make the learning more "cool". But deployment of assignments with complexity requires a level of ops sophistication many teachers lack.

16:14 @ThePrimeagen in Germany we actually have vocational training, spanning 3 years for two separate occupations. IT specialist for system integration and IT specialist for software development.

I don't even do git add . That's too much repetitive typing Git config --global alias.cmt "git add ." && "git commit -m" That might not be totally correct from memory but then you just type git cmt and it adds all the files and you add a message all in one go.

@OnlyForF1

24 күн бұрын

Just use git commit -am

@ShootingUtah

24 күн бұрын

@@OnlyForF1 but typing commit is too long haha I just want to type cmt. Or do you mean in the alias? I think I might have tried that but git didn't like it for some reason.

I never nav to top then `git add .`, since I can stay right where I am and `git add -A` in place. Keeps the context of my mind and the current dir coherent.

Really fresh coffee has oil floating on top. Just a few beads but they’re there!!

Pull main into your branch, resolve commits, push and squash back into main. Clean, fast, easy, and hides the horrors that happened on the feature branch. Also supports reverting.

I learned git at work when the R&D team started letting me do bug fixes

41:00 Basically ThePrimeagen elevator pitch for the coffee is "This is targeted to developers and will have the same price as Starbucks but higher quality."

Can't wait to check the git course out. But, Lazygit ❤ check it out!!!

I’m deep in the sauce and I still do git add . , git commit, git push… I just run git status and git diff -staged 400 times before because I’m apparently cyber ocd

I learned git on college, graduated like 10 years ago Went to SUNY potsdam and they had their own git server, and all the computers in the comp sci computer labs ran Linux

@codyhamilton7682

18 күн бұрын

It wasn't for a specific class or anything, one professor just required you to use it for any assignment you submitted

38 minutes in: Brasil mentioned!!!

You can revert a merge as well. Not just commits. So the argument at 27:00 is not really good in my opinion

Where is his git course ?

@Kajuk

24 күн бұрын

Frontendmasters

@backendbanterfm

23 күн бұрын

www.boot.dev/learn/learn-git

Good grief, we had trade schools, polytechnics, apprenticeships up til the 1970's. Only 10% of kids went to university to float away in academia and research etc. Since then we had the big push to get every kid a "university" education, which involved renaming all the trade schools and polytechnics to "university". Along with the whole disaster of kids having to borrow piles of money to do the study that is now demanded of them. No longer any chance to get a grant or work and study. And of course the bachelors degrees simply got devalued, unless you were one of the luck few to go to a traditionally renowned university. I have been watching this disaster unfolding since I graduate in 1979.

Finally I might end the debate. "Why use neovim? VSCode so pretty. VSCode so kewl" but can it order COFFEE?

My 2 favorite devs

22:00 it will walk the first-parent. In Git, first-parenet of a merge commit is the current checked out branch while merging. So HEAD~2 will walk the first parent path. Specificying the first-parent argument when running git log is really nice cause it takes out all the noise of side/feature branches.

beastco mentioned

@backendbanterfm

24 күн бұрын

Shout-out beastco

git push --force-with-lease aliased to gpf for safe and fast push forces

lol its funny thats how things were in the late 90s early 00's for Web Development. It was considered a trade at that time...Honestly I think they should keep the CS Model for the first 2 years and the second 2 is a straight up bootcamp...similar the Software Engineering degree but more in depth.

I don't think universities should teach any specific tools, but rather more theoretical foundations which are universal and don't become that quickly stale. Teaching specific tools / languages is totally fine for more vocational institutes where you need to learn stuff that is directly applicable at work. Having said that using particular techs/languages as an example is probably great idea, but I'd rather see graph theory and conflict resolution algorithms taught at unis than particular tool

Did I just watch Prime invent run length encoding in real time?

Or... you just use git feature built into intellij. I have used so many git tools as well as git cli and there's nothing easier and faster to use than the feature simply built into intellij. No git add -a. Everything you want to be added is just automagically added

Before Git, We learn FTP, then SCP and Rsync

a tool is something you gotta respect and so, I hear ya about, when schools teach git, but don't teach it properly, they are giving people credit for knowing something they don't really know. And it comes across anyway as, they don't respect the tool

git add -u is the perfect compromise

I use lazygit. I still do file by file cuz it also gives me a chance to kinda glance review but with lazygit its easy. I dont feel safe adding all 😂

Ahh, the deep words of Samuel Coolranch.

Prime's sweatshirt dead giveaway "dad with small kids"

I really like actually preserving the history of the existence of a branch. I cut feature branches from master, rebase them back on master whenever master has changes, and then I _merge_ the feature into master when it's done. Then if my feature has a critical bug we revert the entire merge. Edit: also git push --force-with-lease exists and is wonderful.

So. Prefer tea over coffee (well I just don't like coffee at all) Indeed. I rebase my branch as much as I want to, until I made a pull request and need to fix comments. Then squash and merge when done.

Bachelor's degree in Sweden is 3 years.

Always rebase your branches before merging a pull, and generally squash merge each pull request. If you rebase frequently, any issues rebasing are very manageable. And if you feature branch gets really big (and does and undoes and modifies itself in a place that may have changed on main) then you can squash some of your commit in the branch and then rebase.

If your CS curse didn't teach you GIT by year 3, you should be able to get full refuns in that shit. It's literally like if driving class would just nit teach you how to check oil in your car, cause "it's theory of driving, not real driving here".

8:29 that’s a good take. Uni should teach how to build git, not how to use git.

Friends, 'git add -u' is the way

Implementing version control would not teach fundamental CS aspects like implementing a compiler or OS. So implementing version control would not be the best use of time. Teaching the basics of using version control is a good idea because it is a great tool. Much like teaching LEX and YACC is a great idea. But schools should stick to the basic fundamentals of CS - basically the stuff that does not change. People can learn the stuff that changes quickly on their own.

@7th_CAV_Trooper

24 күн бұрын

Seems like understanding the challenges of distributed systems would be a good idea.

Technically, I have a proposal. What if we remove useless degree. Like instead of having phd or masters, we should just have professional degree. So you can have bachelor's degree in computer science (this teach you the basics and fundamental concepts) Then you can get the Professional degree (which teach you businesses setting, corporate, how programming is done in those setting) Just to note. Every business and company is different. You can't technically teach everything, but at least Professional Degree should teach you how real world works.

This take on not teaching git is a good take. Like learning to edit movies with razors and tape before they give you a computer. True.