eddd-ddde

6 ms·

61.
by eddd-ddde 9mo ago
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
62.
by eddd-ddde 9mo ago
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
63.
by eddd-ddde 9mo ago
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.
64.
by eddd-ddde 9mo ago
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.
65.
by eddd-ddde 9mo ago
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.
66.
by eddd-ddde 9mo ago
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 monorep
67.
by eddd-ddde 9mo ago
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 y
68.
by eddd-ddde 9mo ago
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.
69.
by eddd-ddde 9mo ago
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,
70.
by eddd-ddde 9mo ago
Did you try clicking one link into "about" and reading one paragraph of text?
71.
by eddd-ddde 10mo ago
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.
72.
by eddd-ddde 10mo ago
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.
73.
by eddd-ddde 10mo ago
> 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
74.
by eddd-ddde 10mo ago
Not to be confused with the ABA problem*
75.
by eddd-ddde 10mo ago
You forgot option 3. Private companies stop profiteering from healthcare.
76.
by eddd-ddde 10mo ago
> Stacked pull requests using Jujutsu's change IDs. Now I'm very interested. Will definitely give it a try.
77.
by eddd-ddde 10mo ago
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 ac
78.
by eddd-ddde 10mo ago
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 mem
79.
by eddd-ddde 10mo ago
"someone will look at this issue soon" (3 years later...)
80.
by eddd-ddde 10mo ago
What about _most_ comments are bad?
81.
by eddd-ddde 10mo ago
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.
82.
by eddd-ddde 10mo ago
Why use atomics if you don't need them? There really should just be two different shared pointer types.
83.
by eddd-ddde 11mo ago
So your claim is that buggy software is better than documented buggy software?
84.
by eddd-ddde 11mo ago
What does XSLT provide that you cannot achieve with plain JS?
85.
by eddd-ddde 11mo ago
What you are talking about is solved by jjs auto rebase behaviour. If I amend a commit, all children are rebased automatically.
86.
by eddd-ddde 11mo ago
> 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.
87.
by eddd-ddde 11mo ago
You could probably use bookmarks for this.
88.
by eddd-ddde 1y ago
Wouldn't the old school style be more like rust async? Simple structs that you poll whenever you need to explicitly. No magic code that looks synchronous but isn't.
89.
by eddd-ddde 1y ago
Where could someone get started in terms of reading material to learn more about this in depth?
90.
by eddd-ddde 1y ago
How is it different from the classic corporate caricature of a person with unnatural body proportions? It's just art style.

More ›