This indicative mood is something I would send back for correction or correct myself where I am the maintainer. However I understand that although this is pretty consistent through FOSS, it is not a settled matter especially in corpo-land. Most important is that it is consistent within a project. See many differing views here on Stackoverflow, noting the most popular answer though is imperative as Linus requests.

And here it is in the kernel contribution documentation.

Simple example:

• bad: Added foo interface.
• good: Add foo interface.

So the commit says what applying the patch will do, not what you worked on.

I didn’t say the source of failure. I said a source of ambiguity. And having also been in the industry for decades, I have encountered it many times, where a junior programmer or somebody new to a project read some documentation and assumed a behavior which in fact did not match the current implementation. So you may have been fortunate, but your experience is certainly not ubiquitous.

With respect to variable names, I’d suggest those too should absolutely be updated too if the name is given in a way that adds ambiguity.

I’m not saying comments are bad; rather that bad comments are bad, and sometimes worse than no comment.

And your colleagues are probably correct with respect to this sort of «what it does» commenting. That can be counterproductive because if the code changes and the comment isn’t updated accordingly, it can be ambiguous. Better have the code be the singular source of truth. However, «why it does it» comments are another story and usually accepted by most as helpful.

No I’m Spartacus.

It really forks the llamas ass!

That belongs on /c/extremelyenraging.

Fortunately, they aren’t being asked to do that. All the rust team was requesting was metadata about the call signatures so that they could have a grasp on expected behavior.

A bunch of people that either failed to understand the value of the moderation system or are just crybabies about being expected to follow the rules answering here.

It is easy to use and not nearly as toxic as most of the internet will claim. Research your question, ask clearly, include the code you attempted for a minimal reproduction, and include debugging details. If you don’t do those things, you are the problem, not the people closing your questions.

I use it often per month.

I don’t either, but you don’t have to use that feature. I don’t. I just use with local db for that machine.

I use fish with atuin but without sync. It is nice because I can search commands for a given workspace. For example the commands within a given git repository.

Also, atuin.sh.

There is no USB-B here and it is pretty hard to get the wrong direction anyway.

Six since it has A at both ends.

If you can write a moderately complex math equation in tex on the first try, you’re a programmer in my book.

Like all other patterns, it can be done well or done poorly. I’ve experienced both with monorepos. The pain is greater when it is painful. But if the contribution, build, and release procedures are well designed and clearly documented it can also be nice.

Aren’t the x-suffixed files just an xml format?

Comapnie bro!

I meant doesn’t change with respect to time zones. Leap times are still relevant in that scenario as each solar rotation doesn’t divide into a whole number of days and leap seconds due to variance in rotation.

With respect to the meridian I envision it rotating around the earth once per year, hence sidereal. So 0000 would rotate around the earth through the course of the year. Each day it would be one degree farther.

Most likely is I’m just completely full of shit.

My suggestion has always been universal sidereal time. It is singular, doesn’t change, and carries no colonial baggage since it rotates around the whole earth. Even suitable as a home time if we become spacefaring.