It's not that hard, the US just didn't want to do it for whatever dumb reason.

to "so basically Iran would get everything it wants under this plan".

I'm not so dumb to understand that this will be the final plan, just commenting that this is incredibly bad for the US as is laid out.

> Any review of the actual deal would show a two week ceasefire in exchange for the strait being open and safe while negotiations continue.

Speaking of this community being kinda dumb - do you really think this ceasefire is enough for all ships to go on their merry way? Deals mentioned over social media are not enough to convince insurance companies that all is safe. And 12 hours later we now have evidence of this - https://www.nytimes.com/2026/04/08/business/strait-hormuz-sh...

Also, my original point is that there is nothing in that deal that is a better long-term outcome than what we had before the war. Maybe that will change in the final deal, but the fact that the starting point of the negotiation is 100% on Iran's side is not where you want to be.

I feel like what you're arguing is that you should clean up your commits before anyone else sees them. Fair. But you could also clean it up right before merging to main. It's not that different, except the latter is much less annoying, particularly when going back and forth with people.

I know this is a very github centric workflow, but that's where most engineers work now, and it's nice and easy. This wouldn't work for eg: contributing to linux, but that's not what most of us do.

And to counter some specific points:

* In a github PR, you write the main commit msg and description once per PR, then you tack on as many commits as you want, and everyone knows they're all just pieces of work towards the main goal of the eventually squashed commit

* Forcing a clean up every time you make a new commit is not only annoying extra work, but it also overwrites history that might be important for the review of that PR (but not important for what ends up in main branch).

* When follow up is requested, you can just tack on new commits, and reviewers can easily see what new code was added since their last review. If you had to force overwrite your whole commit chain for the PR, this becomes very annoying and not useful to reviewers.

* In the end, squash merge means you clean up things once, instead of potentially many times

Also they just hit a $30B run-rate, I don't think they're that needy for new hype cycles.