throwaw20221107

This is another argument why "not squashing is bad"; because it discourages people from committing.

That's fair. Both overwrite (edit: seemingly overwrite) (un)staged changes. But `checkout` requires less hyphens.

I feel like all of this would be resolved if my boy Linus had renamed `git add` to `git stage` or `git prepare` or something more clear.

Or added some warning, like "all this stuff you haven't committed yet; it's not managed by `git` so don't try to overwrite it all using `git` until you've committed some of it."

Ya this is basic economics, fixed investment vs markup driven return.

merging a sequence of PRs from same branch is bad if you squash

For me in this scenario, merging `main` w/ squash commit back into PR2 branch after PR1 gets merged works here.

As an aside — if code review is the bottleneck, it's probably not a huge investment to do some git fenangling to get the above to merge cleanly.

But I don't see how this use case is a dealbreaker or even specific to squash...? Won't you have to incorporate/merge other devs' changes to `main` back into PR2 anyhow, regardless of whether PR1 was a squash, rebase, or full history?

Sure but the vision/nlp models required to enable context-sensitive vision apps (i.e. an app to "give me facts from Wikipedia about what I'm seeing"), those models are closed and owned by big companies like Google and OpenAI.

The previous two computing revolutions "personal computers" and "apps/websites" were enabled by the openness of the OS and the openness of TCP/IP and browser vendors, respectively. If the next "AR/VR" revolution depends on complex vision models, there's no guarantee they'll be open for independent devs. And judging by the last few years, it's highly likely they won't be.

BTW I think there's good reason they don't release GPT-3 or DALL-E or PaLM or whatever. That shit is dangerous.

Edit: ok you can hack the hardware to let you run the models or make the necessary network calls to run them. That's still way different than Wikipedia which is a first class webapp where you don't have to hack anything to use it.

the truly adversarial case is rare

The problem is not adversarial, or due to malice. The problem is ignorance and expediency driven by a desire to push code and little incentive to cleanup your git history.

The easy fix is to squash PRs.

The hard fix is to enforce that devs become "crafters" and to define what is and isn't "good faith".

The problem is who is doing the crafting. (And the approving.) At least squash based approach limits to 1 the number of commits an untrustworthy "crafter" can occupy.

"Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”

Ratorx, do we work on the same team at google? I feel like I've heard you before?

Ok I agree, you roll back to the known working version. The easiest way to do that is revert the whole PR (or data deploy in case of flags, ofc). My point is not "flags vs. no flags". My point is "each PR should generate one commit because that's easy to revert".

The commit dag of git is a cool feature but shouldn't be in `main`. It's so much easier to work with a linear history and one where each commit contains all the required context to figure out "could this have broken something".

Sure. I'm just talking about binary deploy. Of course you're gonna use flags to flight things in an industry context, depending on the company and its CI/CD practices.

Let's say the binary deploy (before flighting) is fucked somehow. Then what do you do?

What do you mean?

Dev 1: "I would like my PR to make 2 commits into `main` instead of the 1 that everyone else gets via squash."

Dev 2: "Ok then make 2 PRs."

if a PR is broken, revert a simpler commit and just fix that

I guess it differs between "library development" and "service development".

When you're developing a service, what's in `main` is constantly being tested under the production/customer load. So reverting the known bad PR is a faster fix. And the bug is affecting your customers, so you fix fast and cleanup later.

Typically in industry if a PR is broken you revert the whole thing as fast as possible. But most projects in industry are services.

However when you're developing a library you'll probably release via tags. So if bad code makes it into `main`, it's not a huge deal, and it might be clearer to just revert the one (child) commit of the PR. Because there's no time crunch, no bug in prod, nothing affecting customers.

but craft the commits in the PR instead.

The problem with not enforcing squashing is trust. Think about the worst dev on your team:

Given that trust, are they gonna split their PR into useful commits? Fuck no. they're gonna merge into `main` a bunch of commits saying "fix typo lol xd" and "lol I suck".

If you give them the power to not just make 1 commit per PR, but N commits per PR, are they going to fill up your team's history with crap? Absolutely they will.

Squashing is a useful gatekeep in that way, to prevent one person from screwing over everybody else and making it harder to `blame` to rootcause a critical outage.

I'd argue "why a method exists" should be addressed with naming and javadocs, not in the commit message. Why split the meaning of the code between the code itself and the commit messages?

And if it's not possible to document inline, the PR docs or code review comments should address this. Then future onlookers can use `blame` to see the context.

Yeah, seems almost like the downfall was its openness. It's almost a kind of hubris -- he didn't need to articulate his plan in detail via a traceable comm like email, should've been more secretive. Maybe Zuck should've taken a more "first you must deceive your allies" approach.

For me it was effective writing. Simple sentences in active voice identifying clear actors and relationships. Going to apply it to my own technical writing style.

Is it a work of art? No. But he got his point across to me rather clearly.

For context, I have a degree in mathematics. It certainly mirrors the informal-but-precise language you see in the field. Maybe that's why it was effective for me.

I would love to just learn about places where I go passively with AR.

It won't go down this way. Wikipedia for AR will never happen. More likely it'll be thousands of ads and other crap.

Ya, the three arguments are

1. `|`

2. `grep`

3. `"my actual filter"`

The only reason people lose code is because

1. they didn't read this one diagram: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-...

2. And then they run `reset --hard`

Modern Git workflow is very simple on its own:

1. Your codebase has a `main` branch which is write-protected

2. Devs submit changes to `main` from their own branches using PRs

3. Devs can do whatever the fuck they want on their own branch

4. PRs are merged one at a time

5. When merge happens a dev's PR is squashed into one commit that gets appended to `main`

6. If next dev wants to merge their PR with a conflicting change they have to resolve the conflict first and then they merge

7. The end result is that `main` is a linear history of all PRs with the time they were committed to the `main` branch i.e., when they could've started to break prod.

This is a solved problem and it works great in industry. Why break it? If you want interactive rebase then make 2 PRs.

6 months

more like 6 years, unless you're a new grad with no savings, or unless you somehow managed to burn through your 200K/yr salary every year. Probably decades if you migrate to an LCOL.

Edit: oh, you meant 6 months on the severance alone. Yep

Another example: AI research

Lol way too hard given all the politics and gatekeepers in those fields. Doing software is so much easier than that right now.

And I disagree that solving climate change etc. is a "need" for most people. I think we all pretty much accept that climate change is going to happen unless some major coups or revolutions take place, and there's nothing we can do about it. Seems like the plan for the individual is just to ride it out for our 80 years, or until there's some food shortage or water crisis that kills us.

lol exactly (https://xkcd.com/451)

"i need to short a stock"

"have you tried options?"

This title rewrite is really bad. One interpretation of it is basically slandering opensea. I suspect OP (the person who decided to make up a title instead of using the article title) is not a native English speaker, and there are two ways to interpret their title and intentions:

1. they meant it as a question "does backdoor in opensea allow to take anyone's tokens?".

2. they meant it as a statement "backdoor in opensea allows you to take anyone's tokens"

Obviously #2 is a lot worse. Hopefully they just forgot the question mark and weren't intentionally being malicious.

Yes. OP's post doesn't present any evidence that those packets being sent actually contain your personal data. Show us some data from an actual packet or GTFO.

That being said, I don't doubt that they do :)