elpakal

If you really want just one commit on your PR you can reset your branch to its target before you merge:

git reset --soft <target>

Which will undo all commits and leave all modified files in the staging area. Then you can make one commit and force push it to replace your branch @ remote.

I had to read the parent comment twice to understand that it was talking about the date in the title of the post and not anything relevant whatsoever.

I totally agree with your points about rage and engagement. What I'm skeptical of is

> If they get rid of the rage bait and toxicity

because AFAICT Elon wants to make speech more open on the platform, and when I hear that I think -> less moderation, which means -> more opportunity for rage posting, which doesn't really add up in my brain.

If moderators are good, why cant you just hire more moderators?

This

Yep, I understand this could backfire and thank you for pointing it out. It's probably best to let it simmer on HN.

It's just my anecdotal experience with this kind of mentality that the people looking to enlighten us simple minded folk are also using any questioning or opposition of their enlightenment as an opportunity to shame those people that question or oppose. Some kind of twisted competition I guess.

(not to say I don't support enlightenment of certain issues, I do, but with limits)

I was extended an on-site interview at Google and after reading this and the comments I think I'll pass.

below ground

I have a side project named CaseYak and for the first year of it we were forced to use thecaseyak.com because caseyak.com was taken. We looked into the whois record for caseyak.com at the time, and it turned out it was owned by someone named Stephen Casey… who lived in Alaska (AK). So it was casey ak dot com (lol). Not sure what happened to Mr. Casey but the domain just opened up this year.

I think it was meant to be a joke

Yes but it wasnt as easy to find out about and there weren’t as many companies who profited from making these kind of things easy to hear about.

It was awfully quiet over there! Glad to see some in person things coming back around though I wonder what capacity looks like compared to San Jose.

I’m not sure I agree with you about your extra > and will pay for.

People want Reddit, people want FB and Insta. Do they pay for those? I’m not saying those are good or realistic models to follow but I think the scale of your product needs to be taken into account with your statement. ie landing millions of users can forgive the lack of a business plan _at that scale_ whereas a SAAS platform targeting B2B customers should probably require your statement to be true.

> Combine’s API is based on the Publisher and Subscriber interfaces, with operators to connect between them. Its design focuses on providing a way to declaratively specify a chain of these operators, transforming data as it moves from one end to the other. This requires thinking differently about intermediate state. Sometimes this leads to call sites that are more complex than one might expect – especially when working with single values, errors, or data that needs to be shared. async/await’s Structured Concurrency provides us with a new way to express this kind of logic. We can now write asynchronous code that is split into smaller pieces and reads from top-to-bottom instead of as a series of chained transforms.

Ouch! Why would anyone reach for Combine with this available? With the simpler call sites and Linux support and all.

ML inference on device is another big advantage of desktop just saying

I kind of feel like this is just another Sherlock move by GitHb TBH, nothing more. It seems like they see popular apps that tap into GH (I use one that is basically just a feed of GH activity which I actually like) and things like Actions in their "marketplace" as opportunities to gobble up new product functionality into their own platform.

> But that doesn't mean that bug prevention is (or should be) the primary goal of code reviews.

Totally agree and well said. In my experience the mentality that code review should catch bugs puts unnecessary pressure on the reviewer which leads to people not wanting to review code, because what if they missed a bug.

I think it does speak to the power of marketing but that can mean a lot. I’m also not out here trying to get ratings, I’m making things I use and publish them because I think others will too. That’s why it’s free and ad free (and admittedly slow to update).

Also reviews can be paid for…

I do this (kind of too), but instead of an interactive rebase I just do a `git reset --soft <target_branch>`, where target_branch is the local (and up-to-date) copy of my target branch. That gets me one clean commit that I can force push up to replace my branch @ remote.

(This works for me because auditing commit history is not important where I work, if it were I would organize commits better.)

Hey, mine detects and redacts faces too (++text and ++macOS) https://gorp.app

Very nice! This was really the only thing keeping my place of work from migrating from CircleCi to Actions. Well done

Pretty small pile lol. Anything else on there?

Really cool and congrats on the launch! I wonder, how resource intensive is it to develop your supply chain and produce these trees? I wonder if you’ve thought about or quantified what the resource cost is upfront - surely there are energy and transportation needs to make a tree?

Cool idea and best of luck.

April fool's is one month away not today...

> Using a metric like mean time to code change could incentivize brute forcing work. Developers who are aware of the metric may work unsustainable hours and that could lead to burnout. Also, they may try to cut corners on tests, reviews or documentation in order to ship more things faster.

I think this depends on how strongly leadership/management tries to use this metric to change behavior, but in a company like mine where we have a lot of business dependencies, contracts etc which rely on predictions of throughput, this is an important metric for us to predict timelines. It's not used against a team or platform and it is primarily used internally by management and not so much engineering teams which I think is the right way to use it.

How about starting with mean time to merge a code change? I get that there are other variables that contribute to productivity but things like satisfaction, collaboration etc are extremely difficult to measure well and just IMHO pretty tangential (disclaimer - I work on a dev prod team and my entirety of last year was spent building engineering metric dashboards and discussing what to measure, and it's not easy so I get it).

The title says almost exactly what the article title says, I’m not going to add words

I changed the title to say Crypto instead of Bitcoin

Nice, but I'm still not giving Meta anything especially my child's art

You snuck the word negligent in there