dukk

joined 1 year ago
[–] [email protected] 7 points 1 year ago (5 children)

Remember kids, always use protected branches.

[–] [email protected] 2 points 1 year ago (1 children)

IMO for AI to reach a useful point it needs to be able to learn. Now I’m no expert on neural networks, but if it can’t learn anything new once it’s been trained, it’s never really going to reach its true potential. It can imitate a human, but that’s about it. Once AI can really learn, it’ll become an order of magnitude more useful. Don’t get me wrong: all this AI work is a step in the right direction, but we’ll only be able to go so far with pre-trained models.

[–] [email protected] 6 points 1 year ago (2 children)

But that doesn’t really give the creator any views, does it?

[–] [email protected] 1 points 1 year ago

You can get merge conflicts in cherry picks too, it’s the same process.

[–] [email protected] 1 points 1 year ago

Yeah, I am. However GitHub, being the biggest Git hosting provider and all that, makes you use merge commits. FF-merges must be done manually from the command line. While this definitely isn’t a problem for me, many people out there just don’t care and merge without a second thought (which, as I said in my comment, results in having to create a new branch and cherry picking the commits onto there).

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (2 children)

Merge commits suck.

My biggest issue with GitHub is that it always squashes and merges. It’s really annoying as it not only takes away from commit history, but it also puts the fork out of sync with the main branch, and I’ll often realize this after having implemented another features, forcing me end up cherry picking just to fix it. Luckily LazyGit makes this process pretty painless, but still.

Seriously people, use FF-merge where you can.

Then again, if my feature branch has simply gone behind upstream, I usually pull and rebase. If you’ve got good commits, it’s a really simple process and saves me a lot of future headaches.

There’s obviously places not to use rebase(like when multiple people are working on a branch), but I consider it good practice to always rebase before merge. This way, we can always just FF-merge and avoid screwing with the Git history. We do this at my company and honestly, as long as you follow good practices, it should never really get too out of hand.

[–] [email protected] 4 points 1 year ago

To steal the top comment on that video: “That’s what the compiler does. It takes .c files and turns them into .o files.”

[–] [email protected] 1 points 1 year ago

It’s actually a common misconception. Here’s a good article which debunks that. TLDR there’s no true historical evidence that this ever happened.

view more: ‹ prev next ›