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.

It’s mostly about no longer letting Russia have access to the Baltic sea any more. They’ve done more than enough bad shit there to be put in permanent timeout at this point. What to do with the land after that is secondary

Sounds like an efficient way to lose Königsberg, Karelia and Crimea very quickly.

I kind of have trouble not watching the other screens, if they happen to fall within my field of view.

Jellyfin is better anyway

I wish this were true, but as a multi-year Plex-to-Jellyfin migrant, I have to point out that Plex was the better software.

I still choose to run Jellyfin for other reasons (don’t like the commercial path Plex is taking, among others), but I still do miss the better reliability and larger feature set in the Plex software stack.