Bun is used by us in production, in dev, everywhere. It’s great. We don’t even use (p)npm to build js packages on our docker images for apps anymore.
Yes. We like teeth.
You come close enough to the border with your mouth open and your attention diverted…we gonna get them teeth out your mouth.
Real sneaky-like.
Somewhere, a Genie is howling with laughter at the magnitude of that wasted wish.
Because we’re more akin to LLMs than we might be comfortable to admit. Or at least parts of us, subsystems of our psyches… Brains are belief engines more than they are objective parsers of reality.
Odd. I retired from arch to Manjaro. I’m baffled at the depiction of it being difficult. It’s been a smooth 6 years so far…and yes, Nvidia.
Wow fuckin’ wooosh with you and that one hey? Only a very weak beta would feel even remotely attacked by that movie. Good luck Chuck!
“A man could kill from sunup to sunset and still his work would never be done.”
-Ernie Dell
If it’s public, graphic, and serves as an example of what these monkeys will do to one who hordes all the bananas, and deters subsequent occurrence of banana-hording; yes.
The alternative is that we can all passively agree that all us monkeys must go extinct.
Yes, that is another benefit, once you start getting muscle memory with the library. You start to parcel things by context a bit more. It’s upped my habit of discrete commit-by-hunks, which also serves as a nice self-review of the work.
Well, bless your heart. I can remember when I used to mistake stuff like this as the want for people to talk with me; we’re not so different after all.
👏 Super duper this is the way. No notes!
Quasi parallel reply to your other post, this would kind of echo the want for a capital letter at the start of the commit message. Icon indicates overall topic nature of commits.
Lets say I am adding a database migration and my commit is the migration file and the schema. My commit message might be:
🗃️ Add notes to Users table
So anyone looking at the eventual pr will see the icon and know that this bunch of work will affect db without all that tedious “reading the code” part of the review, or for team members who didn’t participate in reviews.
I was initially hesitant to adopt it but I have very reasonable, younger team mates for whom emojis are part of the standard vocabulary. I gradually came to appreciate and value the ability to convey more context in my commits this way. I’m still guilty of the occasionally overusing:
♻️ Fix the thing
type messages when I’m lazy; doesn’t fix that bad habit, but I’m generally much happier reading mine or someone else’s PR commit summary with this extra bit of context added.
Could have been worse. I mean, like, imagine of you were using like CVS and you put a watch on the root! Haha and then like every trivial commit in the repo caused everyone to in the entire org to get an email and it crashed the email servers.
Like who’d even DO that?! Though, I bet if you met that guy he’d be ok. Like not a jerk, and pretty sorry for all those emails. A cool guy.
You nailed it with the critique of commit messages. We use gitmoji to convey at-a-glance topic for commits and otherwise adhere to Tim Pope’s school of getting to the point
100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use reflog
, cos…well, then you done messed up now son… (but even then hope lives on!)
Here’s an example
Say I work on authentication under feature/auth
Monday and get some done. Tuesday an urgent feature request for some logging work comes in and I complete it on feature/logging
and merge clean to main. To make sure all my code from Monday will work, I will then switch to feature/auth
and then git pull --rebase origin main
. Now my auth commits start after the merge commit from the logging pr.
I’ll have you know I’m fully baked, and don’t have any reason not to express myself here, so naturally, I’ma gonna.
Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably main
). This generates a merge commit.
Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.
TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.