raylu

if yes:

while jj does make stacked PRs quite easy, I think this tutorial is mostly aimed at people who are still getting their feet wet and not making stacks of PRs. and if the expert is intimidating, tell them to be helpful or fuck off

if no:

well I don't understand your question, but probably don't `jj edit` the commit at the bottom of a stack; `jj new` and, when you're ready, either `jj squash` it down or `jj rebase -s @ -A @-` your change into the stack instead

with jj, you have the option to fix half of it and come back later. you can take a look and see how bad the conflicts are if you go a certain route and compare to another option

bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear

in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases

one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)

I probably originally had 2 expressions that evaluated to booleans. I may have been using `is` to check that the type of one was actually a bool rather than just falsey.

Yeah, that was a real head-scratcher.

To prevent you from passing a String as a String[Zipcode].

They likely already know where a lot of their failures are going to be even without tests. The effort involved in fixing those known failures alone is prohibitive. The fact that the rest of regression testing will be easier with tests is nice, but doesn't reduce the work required to a level where they can justify doing it.

Now you can (at least partially) avoid writing new code that wouldn't work on 3,

Once you're on 3, you can just run your code and see if it works on 3. You don't need tests to avoid writing code that works on 2 but not 3.

as well as gain the option of refactoring things to resolve compatibility - with lots of freedom to decide how much effort to spend on that if any.

I don't think resolving compatibility issues is optional...

See that place running COBOL? Yeah, that's your bank.

Except the ones that are too big to fail right?

https://bugzilla.mozilla.org/show_bug.cgi?id=647959

Configuration should not be able to cause your software to segfault. Configuration shouldn't be software. And, in case it's not clear, configuration should not be written in C/C++.