No.

The cases where bisect fails you are, basically, ones where it lands on a merge that does too much - you now have to manually disentangle the side that did too much to find out exactly what interaction caused the regression. But this is on the rarer side because it's rare for an interaction to be what caused the regression, it's more common that it's a change - which will be in a non-merge commit.

The squash merge workflow means every single commit is a merge that does too much. Bisect can't find anything useful for you by bisection anymore, so you have to get lucky about how much the merge did, unenriched by any of the history that you deleted.

Somewhat Linux-like. You could probably improve it purely from a git perspective by letting subtask dependencies be many-to-many (the commit graph is a dependency graph), but what you have is probably best for your whole Jira workflow.

I agree.

I set merge.ff = false and alias ff to merge --ff-only. I don't use pull but I do have pull.ff = only set, just in case someday I do.

The graph log and the first-parent log serve different purposes and possibly shouldn't be the same command conceptually; this varies by user preference but the first-parent log is more of a "good default", generally. Merges do say "Merge" at the start, after all.

This is what I advise people to do in consulting engagements, too, it's not one of my personal quirks.

It's like switching to jujutsu gives people some kind of mental permission to do this - jujutsu justifies its existence just by that alone, really.

Even even worse, angry all-caps shouting will make it more stupid, because it pushes you into a significantly stupider vector subspace full of angry all-caps shouting. The only thing that can possibly save you then is if you land in the even tinier Film Crit Hulk sub-subspace.

I touch on this a bit in the piece I wrote for normies, it helped a lot of people I know understand the tech a bit better.

Is this true for anything beyond the simplest LLM architectures? It seems like as soon as you introduce something like CoT this is no longer the case, at least in terms of mechanism, if not outcome.

No, you can do it on all the major providers for either no or low cost.

Disregarding the grandfathered free accounts, own domain is $7.20/user/month on gmail, €5/month on Proton. On microsoft that's business tier feature and AFAIK not supported at all on Yahoo.

Zoho Mail Lite is $1/user/mo when billed annually.

https://www.zoho.com/mail/zohomail-pricing.html

A few DNS hosting companies still bundle in a few free email mailboxes with registration costs but that is becoming more rare.

Many people use it like this - this is playing to its strengths, rather than trying to work around its weaknesses. "What's the idiomatic X language way to do Y?" gets you a solid, useful answer in seconds.

But it's just a damn good tool, not the apocalypse/the thing that lets you finally fire everyone. So it kind of gets lost in the hype.

I am not a software engineer, although I do write programs. What is it about digital infrastructure that requires maintenance? In the natural world, there is corrosion, thermal fluctuation, radiation, seismic activity, vandalism, whathaveyou. What are the issues facing the arxiv demanding the attention of multiple people 'round the clock?

They have to update the software stack, replace usage of deprecated APIs, support new latex packages etc. They could probably minimize these by limiting the scope but just keeping a small, tightly scoped software functional is always boring, people want to work on fun new features, they enjoy the brand recognition and feel like they should do more stuff.

I wonder when they will introduce the algorithmic feed and the social network features.

Tools eat up so much context space, too. By contrast the shell tool is trained into Claude.

It's the best starting point in many ways!