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.

Looks like a category theory book. And they’re right: using A to notate the identity arrow is ridiculous.

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 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.

And I"m saying that doing with merges (and squashing) what should be done with rebases is bad. You can do it that way, but you shouldn’t, because it makes for worse history and less usable git tools.

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.

You don’t share feature branches. So you always know precisely what is shared history: the commit you branched from.

The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.

I rebase dozens of times a day and have never had a single issue with it.

If you’re bothered by repetitive merge conflicts (which, in my experience, are quite rare if you’re doing things correctly), that’s what git rerere is for.

Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.

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.

Obviously not, because that’s not possible.

Not sure why, seems just like useful advice. It sounds like the author does contracting of some sort, so having tools to quickly orient around a new codebase makes a lot of sense.

Except, unlike computers and the internet, AI is not essential, unless your whole business revolves around it (in which case, good riddance).