eddd-ddde

I always find these articles really interesting, maybe it's just the way my brain works but I can't ever find any meaningful differences or issues with any of the examples.

> but as noted we found this quite obvious to the eye as well

... and then 2 images that look exactly the same to me :(

+1

Nowadays I just use fish with the out of box installation and it fits all my needs.

I definitely prefer public private over case defined visibility.

You can't use an array for different types.

Matching _is_ useful, no one uses matching just because it looks "cool".

You can have explicit forced AND exhaustive error handling without exceptions. Go actually lacks this.

It totally depends on how you want to test releases. You can have nightlies that deploy the latest green commit every day, do some QA there, then once it is feature complete promote it to a stable release that only cherry picks fixes, then finally promote it to production.

It will be highly dependent on the kind of software you are building. My team in particular deals with a project that cuts "feature complete" releases every 6 months or so, at that point only fixes are allowed for another month or so before launch, during this time feature development continues on main. Another project we have is not production critical, we only do automated nightlies and that's it.

It depends a lot on a team by team basis as different teams would like different approaches

In general, all new code gets added to the tip of main, your only development branch. Then, new features can also be behind feature flags optionally. This allows developers to test and develop on the latest commit. They can enable a flag if they are interested in a particular feature. Ideally new code also comes with relevant automated tests just to keep the quality of the branch high.

Once a feature is "sufficiently tested" whatever that may mean for your team it can be enabled by default, but it won't be usable until deployed.

Critically, there is CI that validates every commit, _but_ deployments are not strictly performed from every commit. Release processes can be very varied.

A simple example is we decide to create a release from commit 123, which has some features enabled. You grab the code, build it, run automated tests, and generate artifacts like server binaries or assets. This is a small team with little SLAs so it's okay to trust automated tests and deploy right to production. That's the end, commit 123 is live.

As another example, a more complex service may require more testing. You do the same first steps, grab commit 123, test, build, but now deploy to staging. At this point staging will be fixed to commit 123, even as development continues. A QA team can perform heavy testing, fixes are made to main and cherry picked, or the release dropped if something is very wrong. At some point the release is verified and you just promote it to production.

So development is always driven from the tip of the main branch. Features can optionally be behind flags. And releases allow for as much control as you need.

There's no rule that says you can only have one release or anything like that. You could have 1 automatic release every night if you want to.

Some points that make it work in my experience are:

1. Decent test culture. You really want to have at least some metric for which commits are good release candidates. 2. You'll need some real release management system. The common tools available like to tie together CI and CD which is not the right way to think about it IMO (example your GitHub CI makes a deployment).

TL:Dr:

Multiple releases, use flags or configuration for the different deployments. They could all even be from the same or different commits.

I'm not sure where you got that from. There is a single branch, which obviously has code review, and reverts work just the same way.

What there isn't, is long lived feature branches with non-integrated changes.

Can you clarify why it would impact project duration?

In my experience development branches vastly increase complexity by hiding the integration issues until very late when you try to merge.

What you really need is stacked changes, where each commit is reviewed, ran on ci, and merged independently.

No information loss, and every commit is valid on their own, so cherry picks maintain the same level of quality.

That's why I mention having real stable APIs for cross-service interaction, as you can't guarantee that all teams deploy the exact same commit everywhere at once. It is possible but I'd argue that's beyond what a monorepo provides. You can't exactly atomically update your postgres schema and JavaScript backend in one step, regardless of your repo arrangement.

Adding new APIs is always easy. Removing them not so much since other teams may not want to do a new release just to update to your new API schema.

Yeah, all new commits are merged to main.

The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it.

Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that aren't ready, so you just cherry pick the fix to your release.

It's branches in a way, but _only_ release branches. The only valid operations are creating new releases from head, or applying cherrypicks to existing releases.

I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.

I am a huge monorepo supporter, including "no development branches".

However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo.

Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

Did you try clicking one link into "about" and reading one paragraph of text?

Nothing lasts forever. The second you decide to use a new 3P API you have to understand it might disappear one hour after your production launch, and that's okay.

The electoral college system wouldn't be nearly as bad of a system if you couldn't just rearrange some borders and suddenly change the results.

> Rebasing is not that hard.

No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD.

There's simply no excuses for git being this unusable for the very simplest operations I do day to day.

Not to be confused with the ABA problem*

You forgot option 3. Private companies stop profiteering from healthcare.

> Stacked pull requests using Jujutsu's change IDs.

Now I'm very interested. Will definitely give it a try.

I absolutely hate companies thinking they are being smart by blocking foreign IPs from using their websites.

Every single time I want to order a burger from the local place, I have to use a VPN to fake being in the country (even though I actually am already physically here) so that it will let me give them my money.

My phone's plan is not from here, so my IP address is actually not geographically in the same place as me.

Wrong, it makes good designs easy to write with clear safe APIs. If you know what you are doing just create a safe wrapper over unsafe functions and do what you need.

For example you can just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API. now you only need to pay attention to those specific unsafe calls.

"someone will look at this issue soon"

(3 years later...)

What about _most_ comments are bad?

The answer is obvious, YES, specify your language version. Every single compiler invocation for production (for example ci builds) should explicitly select a version. Otherwise you are asking for trouble.

Why use atomics if you don't need them? There really should just be two different shared pointer types.

So your claim is that buggy software is better than documented buggy software?

What does XSLT provide that you cannot achieve with plain JS?

What you are talking about is solved by jjs auto rebase behaviour.

If I amend a commit, all children are rebased automatically.

> I do fully understand people who can't get their heads around threads and prefer async.

Those are independent of each other. You can have async with and without threads. You can have threads with and without async.

You could probably use bookmarks for this.