diff --git a/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts b/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
  index 7d677477e..39502f245 100644
  --- a/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
  +++ b/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
  @@ -21,10 +21,9 @@ export function isInSimulatedCurrentBranch(
                // change is  not in a conflict
                eb("change.id", "not in", (subquery) =>
                        subquery.selectFrom("conflict").select("conflict.change_id").unionAll(
  -                             // @ts-expect-error - no idea why
                                subquery
                                        .selectFrom("conflict")
  -                                     .select("conflict.conflicting_change_id"),
  +                                     .select("conflict.conflicting_change_id as change_id"),
                        ),
                ),
                // change is in a conflict that has not been resolved

Conclusions:

* Standard Starship is probably good enough for HLS

* Simple coatings and/or a specific orientation makes things a lot better

https://www.gocomics.com/tomthedancingbug/2015/03/12

I really liked the cross-language aspect of Bazel. Having one command that could compile everything and produce a deployable container in a highly reproducible way is great. It really cut down on "what's your compiler/tool version etc."-type back-and-forth during debugging with other engineers.

The bazel JS/TS rules were tough to work with when we first started using it for JS (2018 I think), especially since we were using create-react-app at the time, and that didn't mesh well with the way bazel wants to work. It's gotten a lot better though.

If I was making the choice from scratch in a new company/codebase, I think it'd really depend on the team. You kind of need broad-based buy-in to get the full benefits IMO.

Have you done this? I picture burning some kid-energy during those breaks. I'm genuinely curious about how that ends up impacting the trip experience.

compared to gas?

It could at least address some kinds of misleading editing. In the political use case, maybe the candidate posts all their event audio and records the hashes on chain. Then they can't change the content of any of it without getting caught. And if someone else posts an edited version, the edit will have a later timestamp, and the candidate can point to their original earlier version and prove that it's the original. That lets everyone else determine which version is the original and which version is the edit.

https://twitter.com/balajis/status/1583495595737481217

https://www.hollywoodreporter.com/lifestyle/lifestyle-news/h...

It's not a "wild conjecture".

"Tweets that share someone else’s historical (not same-day) location information are also not prohibited by this policy."

But with the translation, I just devoured and appreciated it.

which goes at more-or-less the same problem from the other direction. Josh helps with treating a monorepo as separate repos, as opposed to git x-modules' approach of treating separate repos as one repo. Either way, the idea is to try and get the benefits of both monorepo and multi-repo styles, while avoiding/mitigating the disadvantages.

HN talked about it 11 months ago: https://news.ycombinator.com/item?id=27844363

Anyone have experience/updates to share since then, or a comparison with git x-modules?

Not so much for disagreeing. More for engaging a lower-effort way (than the person you were talking to) and appearing to assume that burntsushi was coming from a place of ignorance.

> The whole "general-purpose regex engine" thing was moving the goalposts in the first place and not very relevant to this whole discussion anyway. EDIT: I'm not saying that these distinctions don't matter at all, rather what I want to say is that it doesn't make sense to implicitly call upon a subjective and arbitrary standard.

"general-purpose regex engine" is a direct response to "most regexp libraries are stuck in the 80s/90s". It's about why the regex libraries most people use (the general-purpose ones) haven't adopted the ideas that you're advocating. Seems on-point to me; on HN most readers will be mainly familiar with the general-purpose libraries, so they'll be thinking in terms of those.