laughs in WASM

And people give Python shit for significant whitespace 😂

Appreciate the feedback, thanks!

That came across my recommendation queue the other day - despite my dislike for horror, it looks interesting enough that I might check it out!

It is absolutely insane to me that people rag on the Python packing ecosystem when TypeScript exists. Sure, Python’s not perfect (Rust and Go seem better, from the small amount I’ve dabbled with them), but way easier and more stable than any TS project I’ve worked on.

With a K!

Good work, 47. Now get to an exit.

I don’t understand the question. I don’t want it to mean anything - I just want to know what they meant by it.

mandatory downtime between fights that punishes trying to brute force practice them

Fascinating. This would frustrate the hell out of me - if I’m trying to get better at something, the last thing I want is enforced wait-time between practice attempts! Still, I’m glad you’ve found other games that you enjoy more rather than being influenced by the Internet’s collective fan-boner for FromSoft.

What does this mean?

If you don’t enjoy practicing bosses, FromSoft games will probably not be for you.

This is not a dunk! There is nothing inherently superior or worthwhile about games that require practice. I personally enjoy Soulslike games, but people who claim they’re they’re the One True Genre are just fooling themselves.

TypeScript is far more widely-used than Go.

This Is The Way.

You’d hope so - and if one does, I have no concerns about whatever one chooses to do in the privacy of their own branch - but some people insist on directly merging to main (preserving two parallel histories), rather than squashing their change into a single commit. Savages ;)

Thanks! I’ve been tinkering with VS Code (migrating from IntelliJ) recently - I’ve found that they’re at pretty-much feature parity. VS Code makes it much harder to attach a debugger (IME, though I might just not grok it yet), but is more customizable and a lot less of a memory-hog. I think I’m comfortable adopting it as my daily driver. And, as you say, any IDE’s Merge Editor is usually clearer than the equivalent direct from the CLI!

However, I wasn’t complaining about Merge Conflicts - I do dislike them, but they’re a necessary evil (well, until AI can resolve all conflicts itself :P ). Rather, I was complaining about Merge Commits. See my comment here for more context.

I’m guessing you don’t mean commits that actually bring updates from a different branch in?

Yep, in part, I do. Say I’m working on feature which branched off from main. Time’s gone by, and there have been commits on both feature and main. I want to integrate (not I am very carefully not using the word merge!) the commits that exist on main into my feature branch so that I can use them. You can make a merge commit to do so, but there’s no point in doing so - a git pull --rebase will have the same effect (“My local branch contains both the changes from the upstream, then the changes that I myself have made ‘on top of’ them”) without requiring a merge commit.

But really, what one chooses to do in the privacy of one’s own branch is no concern of mine. I can advise and opine, but it doesn’t really affect me. What does affect me is when people insist on merging into main. That really irritates me, because it results in horrible tangled non-linear history like this. Ideally, the history of main should be a linear history of changes which each follow on from one another, and a commit and a change are in 1:1 correspondance:

• the question “which commit is the parent of this one?” should have one answer, not potentially-multiple.
• there is no value in seeing the development history of the change (all the random “bugfix”, “maybe this will work lol”, “correct typos” commits) in the history of main. They are maybe useful in the PR, but the change as seen in main should only contain the finished polished-up result.

GitHub’s confusingly named “Squash And Merge” (it’s a “merge” in the git merge sense, but it doesn’t create a Merge Commit! “Squash and commit” or “Squash and push” would be more accurate) results, I think, in the outcome - a single commit on the HEAD of the target branch containing the result of the change. And if that happens, then I don’t care if you’ve been pulling in changes from main to feature via Merge commits or (correctly IMO) via git pull --rebase - because, whatever you’ve done, your development history will be (correctly) invisible from the commit on main.

(I say “I think” there because I’ve only recently started using GitHub in a professional capacity. For the decade prior to this I worked at a Big Tech company which had its own in-house Code Review tools which - probably not by coincidence - aligned a lot more closely with how I think about how Git history should be structured)

God I fucking hate merge commits.

Personally I (a straight person) use it in an attempt to normalize the term, so that people who want to conceal the gender of their partner have plausible deniability. If all straight people say “girlfriend/boyfriend”, then anyone saying “partner” is outed as “a non-straight person trying to conceal the fact”.

EDIT: but also, it connotes a deeper level of trust, support, intimacy, etc. A “girlfriend” is some chick I fool around and have some fun with; a “partner” is someone with whom I’m building a life together.

Can you talk more about this? I’ve never heard that tagline and can’t figure out what it’s supposed to mean.