Gentlemen! My fellow whites! Let's raise a glass to this pyramid of money. The foundation of which was built upon our favorite pastime: f*cking the poor!
I wonder if those same people would think the guy who delivered the series' opening monologue was the good guy?
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:
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)
I still think the finale of The Good Place beats it, but the competition is close!
God I fucking hate merge commits.
Treat words as coordinates in the space of all possible concepts, and add a few together. I think that fulfils your constraint of not "taking inspiration from...words from a recent ongoing conversation" since you can, if you wish, pick the words in your own head.
Or - drugs. Drugs are good too. I don't know why you're applying these artificial constraints to this problem as if there is some notion of "purity" or "cheating" to the practice of idea-generation. Is an idea any less worthy, insightful, or useful because you came up with it while using a chemical tool to do so?
I think you're being a little too quick to judge (no pun intended) by dismissing these scenarips as assigning blame. The point of these problems isn't to decide whose "fault" it is or who is the "bad guy" - they are thought experiments to explore what is "right" to do, according to various schools of thought.
In the original trolley problem, or in this one, it's totally fair for you to say "whatever happens, it's not the chooser's fault - they were forced into this position, and so they cannot be to blame". That's fine - but even if they are absolved of blame the question still remains of what is right for them to do. If your answer is "whatever they want (because engaging with terorrists' demands is always wrong)", or "whatever is the opposite of what they're being pressured to do", or "whatever is the least action", or "whatever rminimizess suffering", or "whatever minimizes undeserved suffering", those are all still answers to the question, without any implications of blame or guilt to the chooser!
I'm truly impressed at how incomprehensible this post is to me. "Treat", "struggle", "hog" and "chud" all presumably mean something particular to you.
No insult intended - in-group slang is fun sometimes. It's just kinda cool to be presented with it - reminds me of the Weird Old Internet.
They make smaller games, still charge full prices, then make DLCs that are relatively small and chare a lot for them.
So you agree with me, then, that the problem is publishers charging a disproportionate price for the amount of content being purchased?
So? If I can manipulate it with my sleeved arm (thus keeping my hands clean), it's still working pretty well. Sure, I'd prefer not to have my sleeve contact something that someone's unwashed hands have been on, but better that than my hand.