expr

I’ve never heard someone say that before. Why would you want one but not the other, if you don’t mind my asking?

Traditionally, the global flag is used to mean global within a line, meaning all matches in a line.

Absolutely beautiful.

I tried out a 4x10 work week for a while and it was alright, but not as great as I thought it would be. Mostly because I had effectively no time during the work week to get any household chores done, so we ended up just cramming everything into the weekend anyway, largely negating the purpose of having the extra day.

But yeah, if I could do a 32 hour work week that would be incredible.

Where I work, they don’t really give a shit if you have to go to an appointment or whatever. You just let people know you’re going to be out at such and such time and that’s it. No micromanaging of time since we’re all adults and know what our deadlines and deliverables are. It’s a salaried position, though.

If I had no flexibility at all that would definitely be pretty miserable.

The reason it’s so popular is because it provides directional navigation on the home row, with the direction that’s by far the most common (down) under your strongest, dominant finger (the index finger).

It’s much better for both efficiency and ergonomics than arrow keys.

Aw man, really? Why do all of the greats have to be so shitty?

The companies generally know it can be gameified. Most people don’t bother, so they don’t really care too much.

Even if Fitbit only allowed data from wearables, you could still hook up a wearable to a fan or similar and get similar results. There’s not really a way to avoid it.

So… did he use ChatGPT to write the contract in the first place? If so, that would fucking hilarious.

We are far from knowing that true intelligence is possible with the computing paradigm as we know it, and indeed, if it’s even possible to do outside of biological systems. So it does require a revolutionary breakthrough in computer science and/or computer engineering.

I have never argued that it is never possible, just like time travel or teleportation is technically possible given a radical breakthrough in our understanding of how the universe works. But as of right now, AGI/true intelligence/etc. is still purely science fiction and LLMs are not even remotely close (and are a complete deadend towards that goal).

It’s only frustrating if you’re solely focused on winning rather than improving, and especially if you do what I so often see, which is view your chess skill as a proxy for your intelligence (and thus take losses as a personal insult).

Smart people are not automatically great chess players. Chess is a skill you can develop that rewards time, dedication, patience, and lots and lots of practice (and losses).

In fact, losing a game of chess is incredibly valuable, and much more useful than almost any other game. You have a complete record of your game, and since no luck is involved, you can study your game and identify where you can improve. Reviewing your games is one of the best ways to get better at chess, and objectively looking at your game from both players’ perspectives also helps to make it more about improvement rather than personal failure. In fact, it’s fairly standard after an over the board game for both players to review the game together on the board and talk through lines and thoughts on the various positions of the game.

It’s one of the things I really love about the game, because it’s always about getting better rather than punishment for losing. It’s much, much better than video games in this way.

When I play chess, I mostly just want to have a good game of chess, even if I lose. I always take the opportunity to play much higher rated players given the chance, because even though I will almost certainly lose, the game will be a very rich one to review and learn from.

Monorepos don’t really change anything. Squashed commits are still not atomic, unless the MR is small enough to fit into a single logical commit. Changes made to say, a database query are distinct from changes made to route handling, yet both might be needed for the overall feature. They don’t belong in the same commit in history.

What they are describing is exactly the rhetoric I grew up absolutely surrounded by. It’s extremely common.

Yeah, the whole thing is one big joke, really.

I mean yeah, I agree that’s unbelievably stupid. But when people talk about guardrails generally, they are talking about controlling the output of the LLM, which is what I was saying is not possible to do.

It’s not possible to add guardrails due to how the technology works.

The fact of the matter is that it should not be used for what it’s being used for at all.

Squashed commits are not atomic, unless the MR is so tiny that it logically fits into one commit. This is often not the case, though. It is frequently the case that the overall task requires modifying multiple different systems, which should themselves be their own commits, with tests for changes added to the same commit that makes the change.

A well-crafted MR should tell a story in its commits, with changes proceeding logically from one another.

It seems to me what you are really arguing against is poorly crafted history, which I fully agree is something to be stamped out.

To address the specific commands you mentioned:

1. That’s… really besides the point of git bisect. It’s binary search to find bad commits. If the selected midway point happens to be a formatting commit (which I’d argue should really be handled by pre-commit hooks anyway) and that commit is broken, it just means that the search proceeds to the midway point between that commit and the known good commit.
2. You can revert a range of commits, but the point of crafting a quality history is not doing things like having separate commits for tests. Tests belong with the code that it’s testing.
3. First off, any reasonable usage of git will have ticket/issue numbers in the commits that you can use to look up the full task information. But also, git blame won’t show the rename commit if it’s a separate commit from any changes (which it absolutely should be, due to how git handles renames). And finally, if you care about getting more detail about why the code is the way it is, git blame isn’t even the right tool for the job anyway, git log -L is.

Rebasing is not dangerous. You can always go back if something is not to your liking.

You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.

Keeping a quality history rather than squashing also makes many other git tools much better, such as git blame, git revert, git bisect, and so on.

It’s fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.