[mmlb]

I've had that same "what's the point" thought every time I've read about stacked PRs, but recently had an (obvious) epiphany. The benefit is you get CI for each commit! I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need.

[satvikpendem]

I don't get it, we already have CI for each commit, at least at our workplace, enforced.

[tabwidth]

Other side of that though, touch the bottom of a stack and every layer above it re-runs. Stack unwinding, basically.

[skydhash]

> I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need.

Can't you run your CI locally? I know it's not feasible for some codebase, but at least the linting, formatting, unit tests, some integration tests should be able to be done locally.

[nijave]

>Can't you run your CI locally?

If you mean automated tests and linters, sure.

Conceptually continuous integration is generally integrating 2+ different lineages of code together which is more common with multiple developers although I suppose it's becoming more relevant with agents creating a bunch of worktrees with different things.

In practice, CI has taken the same path as "DevOps Engineer" ie most people just mean "automated test server"

The opposite of CI is more-or-less merge windows or merge-fest like Linux where everyone mails in their changes and someone manually integrates.

[happimess]

> Conceptually continuous integration is generally integrating 2+ different lineages of code together

> In practice, CI [often means] "automated test server"

Could you say more? I use "CI" to refer to the automated processes that run tests and (maybe) deploy code as it is merged to some blessed branch. It's what continually integrates the new code into the existing code. What am I missing?

[nijave]

If there's 1 developer working on 1 branch at a time: main is at commit A, you branch add B and C, you merge now main is at A, B, C. Your "integration" was just moving the code forward and if you ran tests on A, B, C commits and it passed, the tests would still pass on main.

Now say there's 2 developers that branch off A. Dev 1 removed dead code coolUtil and with it deleted module coolLib and commits B1. Tests pass, code works. Dev 2 adds new coolUtil2 in commit B2. Tests pass, code works. Now they both merge their changes back to branch A so it's A, B1, B2 or A, B2, B1 or A, B3 (merge of B1/2). Anyway, you try to run the code and it fails. Everything merged clean but Dev 1 removed the lib Dev 2 depends on. They didn't create any file level conflicts because they edited different things so the merging went fine however now the code is broken.

The real integration part comes from reconciling different (potentially conflicting) changes and making sure the end result still works. The server is doing the integration automatically and verifying it automatically

You could skip the server and merge everything on your machine and run the tests on your machine and achieve the same result. Still CI, no server, no automation

Hopefully that makes sense, if not I think the Wikipedia page "Practices" section does a decent job separating the pieces https://en.wikipedia.org/wiki/Continuous_integration

[steveklabnik]

You can't have mac/windows/linux/whatever all locally simultanously.

Not every project requires this, but for those that do, it's impossible.

Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly" than it is when it's on your forge.

[skydhash]

> You can't have mac/windows/linux/whatever all locally simultanously.

Why can't you? That's what VMs are for. And even then, most cross-platform codebases have an abstraction layer that rarely changes. So even testing on one platform can raise your confidence very high.

> Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly"

Again why? I wouldn't care about the dev's local branch. But what is send to the main repo can be easily scripted to run the CI on every commit. You just send the result back with each commit that fails. They can replicate the same workflow on their local workspace as a pre-push process.

[steveklabnik]

You can't run MacOS in a VM on non-Mac hardware without violating Apple's EULA.

> But what is send to the main repo can be easily scripted to run the CI on every commit.

Sure, this could work. I didn't say it was impossible, just more difficult. You have to build all of this support on top of the system that already does it for you: have your forge run CI on every commit.

[sfink]

Heh, it's a fun reminder that different people work on different things.

Sure, I could load up my build machine with mac/windows/linux/android, with multiple versions of each. Emulating x86+x86_64+arm32+arm64+aarch64+... is also doable, sort of.

But considering that the real CI runs several thousand hours of tests total across all platforms, I think I won't.

Also, my Electron-based IDE needs those 10s of GB to edit text. How can you possibly edit a 1KB text file with less than 1GB of RAM?

Not to mention clangd that needs to do its ultra-important work Right Now so I can invalidate it all with my next edit. That's probably the biggest RAM hog of them all.