expr

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.

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.

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.

Ever heard of AB testing?

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.

Good, maybe people will use it less.

I really should link people to this site more often. The author is 100% correct.

Meanwhile, vim keeps trucking along, 34 years later.

Obviously don’t have the full context, but rarely is it ever advisable to give third parties direct access to a database. There are many reasons for this, like, for example, the fact that doing so makes schema migrations practically impossible.

No one actually copy/pastes thousands of lines of code. We use libraries.

Languages do matter a lot. Yes, they are all technically equivalent, but the craft of software engineering is much, much more about social/cultural/community considerations than it is computational ones. What the community around a programming language values matters, because it informs a great deal about what’s idiomatic in a language, what libraries are available, what kind of bugs are possible (or not), how easy code is to read, comprehend, and maintain, and much more.

What makes a language good is not what programs you can write in it, but how it constrains what you can do such that you naturally writing good code. For example, null pointer exceptions (or segfaults in C, etc.) are a classic problem that plagues many mainstream languages like Java, C#, Python, etc. In Haskell (and a handful of other languages, including Rust), null pointer exceptions are not possible, because nulls do not exist in these languages. Taking away this language “feature” actually increases the power of the language, because you can guarantee that a certain class of common bugs are not possible in your program. So languages that restrict known bad programming practices lead to programmers writing better programs and, more generally, a community around the language that resonates with these philosophies.