expr

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.

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

He’s murdered a bunch of Iranians, including schoolgirls. So it definitely fits.

As far as gods go, his god is himself, so that counts too, imo.

I stated an assumption and was contributing to the conversation. Even if that assumption is incorrect, there’s no need to be a dick about it.

It seems like a larger atmosphere would result in a longer duration exposed to atmospheric drag, thus requiring more fuel to overcome it.

I assume it’s not just about the gravity, but also the much larger radius of the planet would mean much larger distance from the surface, and thus much more fuel needed.

I mean, we don’t want to lie to kids.

If you take such a broad definition of social media, then nearly the entire Internet becomes “social media” and the term loses its meaning, IMO.

I mean, social media should be banned for everyone, not just teenagers. It’s a great evil in the world today, and in a functional democracy that wasn’t braindead, we should ban them outright for the mass harm and destruction they have caused.

That being said, I fully understand that the motivations of countries for these kinds of bans have little to do with the harm of social media and are much more about surveillance.

Nah, microslop is a great name, especially because they throw tantrums about the name. It’s very descriptive of what they have become.

if you sleep at the same time consistently, changing that is a big change for your body. It takes time to adjust a strong routine, and it takes a physical toll to do so.

We have lots of evidence of it causing all kinds of problems: increased numbers of heart attacks, car accidents, and more. It very much is a detriment to society.

Who are these mythical “real chiropractors” that you speak of?

It’s pseudoscience, and always has been.