Yeah, consistency is good, which is why it’s good to follow the spec. I’m saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.

The spec requires errors to be a single string, and also mandates using the space character as a separator? I’m not a fan of deviating from spec, but those are…bad choices in the spec.

Tortoise git is probably what convinced me to just use the CLI for everything back in the day. Tortoise SVN is basically 1:1 with the SVN CLI (as far as I could tell, at least); Tortoise Git was…not.

Maybe other git UIs are better. I hope so! Maybe even Tortoise has gotten better. But it was not good back then. (This was around 2013.)

For anyone else wondering, here’s the text of the actual email cited as the CoC violation:

Michal, if you think crashing processes is an acceptable alternative to error handling you have no business writing kernel code.

You have been stridently arguing for one bad idea after another, and it’s an insult to those of us who do give a shit about writing reliable software.

You’re arguing against basic precepts of kernel programming.

Get your head examined. And get the fuck out of here with this shit.

I agree, but if you look at the specific email linked, it very clearly crosses the line into direct abuse, whereas most of Linus’s rants do exist in a slightly greyer area (even if they’d be grounds for a discussion with HR at an actual company).

the function reads the comment added after the function is called using a backtrace and uses them as arguments

How marvelously creative. What an abomination.

(I haven’t checked what the warning says today.)

Well, yeah, that’s why the linked ticket led to a massive improvement:

If you don’t know what git is, you should probably avoid choosing the “confirm” option when you’re warned that an operation is dangerous.

That said, I think the change they ultimately made in the linked issue, which words the warning differently and, more importantly, provides an option to only discard changes to already-tracked files, is a vast improvement.

That depends on what you map “discard” to in your mental model. Whoever designed the VSCode feature chose to associate it with reset+clean, rather than just reset. Presumably that’s why they called the menu option “discard” rather than “reset”. (But I agree that this is a surprising choice, and that they managed to make an already-famously-bad UX even worse.)

Well, yeah, that’s why they updated the warning pop-up. It’s still the case that the user didn’t bother to find out what the warning meant before choosing the inherently destructive option.

Here’s the revised pop-up, according to the linked ticket:

I haven’t checked the current behavior (this whole incident was seven years ago).

I meant it in a completely light-hearted way, but I do wonder if some of the downvoters don’t realize I’m talking about the username.

Understandable; no time to check details when your fuse is that short

The second button is actually a pretty major change!

It means both.

It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.

In reality, that was added four and a half years after this issue was opened.

Yes, the dialog was changed, as part of this linked issue (and maybe again after that; this whole incident is very old). After reading some of the comments on that issue, I agree with the reasoning with some of the commenters that it would be less surprising for that menu option to behave like git reset --hard and not delete tracked files.

I think it does make sense to make sure there’s something substantive in the very first message, even if it’s not a complete description of the problem or a concrete request for help.

And the message with my problem tends to be longer and take me more time to type, so there is a delay between “Hi” and the actual issue.

That makes perfect sense, and I see why the habit became so commonplace; but that’s exactly why this is annoying to anyone who is highly responsive on a messaging app, especially if responding to requests for help is part of their professional work. They pay attention to their notifications, so the notifications are probably configured to be noisy. Checking a notification before it’s actionable is a waste of their time, albeit a small one.

Plus, if you force yourself to start typing out the problem before hitting “send”, you’ll often understand the problem better by the time you finish typing. This doesn’t generally mean that you will have solved the problem yourself (though of course that sometimes happens), but it does mean you’ll have more context you can provide as part of the request. And sometimes, you’ll think of something you want to check or investigate before sending the request for help, in which case you’ll be glad you haven’t sent a ping yet.

Finally, you can still split up your messages after typing them all out. Just “cut” all but what you want to send in the first message, send, paste, and repeat.

The user clicked an option to “discard” all changes. They then got a very clear pop-up saying that this is destructive and cannot be undone (there’s a screenshot in the thread).