A merge from upstream once a day, at the beginning of the day.

I’m working on a DevOps setting, and even though we’re a small team, we have about two to three changes going through the pipeline a day.

If you keep your fork too long without syncing, it just get more complicated to merge, and more importantly if you need help from the upstream change author they’ll have moved on to another subject and the change won’t be as fresh in their mind as if you had merged the day after they pushed it.

I’ve had that kind of reaction - on rebases also - and most times it was in fact a code smell pointing to a case of spaghetti code.

If you get to the point that you fear upstream merges/rebases into your WIP, stop for a second and ask yourself if maybe that might be an issue with too much interpendencies inside the code itself. Code should be as close to an directed acrylic graph as possible. (doesn’t count, I was not speaking of git! :b )

Forewarning : ops here, I’m one of the few the bosses come to when the “quick code” in production goes sideways and the associated service goes down.

soapbox mode on

Pardon my french but that’s a connerie.

Poorly written code, however fast it has been delivered, will translate ultimately into a range of problems going from customer insatisfaction to complete service outage, a spectrum of issues far more damageable than a late arrival on the market. I’d add that “quick and dirty code” is never “quick and dirty code with relevant, automated, test coverage”, increasing the likelihood off aforementioned failures, the breadth of their impact and the difficulty to fix them.

Coincidentally , any news about yet another code-pissing LLM bothers me a tad, given that code-monkeys using such atrocities wouldn’t know poorly written code from a shopping list to begin with, thus will never be able to maintain the produced gibberish.

Modular’s Mojo might interest you - it just popped up in my news feed, it’s entirely a coincidence.

Others has answered the specific cases where TTM is paramount.

When time is less of an issue, in my experience it’s in no particular order a mix of:

• product owners or similar role wanting “everything and right now” for no reason whatsoever, except maybe some bonus;
• bosses bossing around to try and justify their existence instead of easying progress ;
• developers being not much more than code jockeys with a tendancy to develop by StackOverflow copy/paste;
• operations lacking time, resources or knowledge to build a proper CI/CD pipeline - when it’s not an issue of operations by ServerFault copy/paste;
• experts (DBA, virtualization, middlewares) being kept out of the project, and only asked for advice when things go terribly wrong later.

All in all, instead of short term profit, it’s a lack of not-so-long term vision and engagement from everyone involved. They just don’t care.

Yeah, I’m the one in charge of fixing the mess, why you ask?

Your question is a bit vague but it looks to me that what you want is some sort of expert system of inference engine.

There might be some open source solutions, and there’s always the GNU Prolog language that might suit your needs.

I suspect that you won’t get a graphviz structure out of it though.

On a side note, w.r.t. keeping the dependencies up to date, have a look at renovatebot. It creates merge request for each and every dependency update, thus triggering a build to check that everything is OK.

We went from a computational tool serving a wide range of tasks to an entertainment widget barely more interactive than a TV were work is an afterthought.

The former was expected to not get in the way of their users, the latter is designed to retain attention as long as possible to maximize consumption