Getting bought is often the whole point for a founder, since that’s one of a few ways for you to get a big payday.

Getting bought only really happens if a majority of the shareholders agree to it, so you can reject it as much as you want.

Chinese EVs have massive tariffs in the west, so I wouldn’t count on this actually happening, unfortunately.

It is the coolest crime after all

It’s mostly a skill issue for services that go down when USE-1 has issues in AWS - if you actually know your shit, then you don’t get these kinds of issues.

Case in point: Netflix runs on AWS and experienced no issues during this thing.

And yes, it’s scary that so many high-profile companies are this bad at the thing they spend all day doing

You enable it using git config, after that it will apply to whatever frontend you’re using.

Depending on how structured your commits have been, it can either be very difficult to get a rebase through or a complete breeze. There are some features to make it easier - rerere being the main one I’m thinking about.

What’s your mental model for a Git commit, and a Git branch?

Once I properly learned those two concepts, understanding rebases became a lot easier.

I’ll try to explain it to the best of my abilities.

• Think of a commit being a patch - a description of how to take a particular file from one state to another
• A branch is a list of patches to be applied in order, from the point where the branch was created until the last commit on the branch

When you rebase a particular branch, what you’re essentially doing is taking all of the commits that are currently on your branch, checking out the other branch, and then applying each of the patches in order on that new branch.

A rebase can be cleanly applied if the premise for each commit has not changed when applied, but if the premise has changed, you get a conflict to be resolved before being able to continue the rebase.

I mentally model a rebase a bit as a fast version of how it would look like to build the branch I was on, but on top of the branch I’m rebasing on.

I’m guessing this is in reference to a scenario where a review of the PR has already been performed, and the rebase+force push is made to introduce new changes to the PR, possibly to address PR feedback.

I agree that these changes should be made in separate commits, for the benefit of the reviewer.

There are other scenarios where rebases are appropriate though, such as getting potentially incompatible changes from the main branch into the PR, and here I believe a rebase+force push is the right tool for the job.

Force pushing is necessary when using rebases, and rebases are an essential tool, so you should not be afraid to force push under normal circumstances.

Don’t be afraid of rebases, they are an essential tool in Git.

This particular fear can only be addressed by understanding.

It’s mostly for undoing a rebase or merge you’re not happy with.

You’re missing some of the code in that snippet, because the author’s markdown rendering isn’t working properly.

Specifically, it’s missing #incluir <iostream>, where the <iostream>-part got treated as an HTML-tag.

Everyone who plays the lottery might be a millionaire too

I honestly think it’s dumber than that - I think he’s still salty about wind farms being put up outside his golf course in Scotland and is taking his petty revenge on the world

Yeah, you can use the Epsilon garbage collector in Java for a no-op garbage collection strategy.

For short-lived programs that do not risk hitting any memory constraints, it makes a lot of sense - zero time wasted on cleanup during execution, then you just do it all at the end when killing the program, which you can do in constant time since you don’t need to reason about what should remain or not.

Complete piece of shit, yeah

Largely accurate apart from special-purpose tools usually being employed instead of ChatGPT

Yes, and it’s one of the most important things I do. Given the AI codegen boom we’re seeing, it’s also the skill I have that is increasing the fastest in value.

Unironically true actually, ffmpeg is everywhere in the video space

That kind of commit quality should only really be permissible on private projects, and as a reviewer, it’s arguably acceptable to reject PRs with this kind of history.

You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.

For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It’s not uncommon for me to have several branches containing a single “wip”-commit which I amend onto while building up the full code for the branch.