I also appreciated that the site didn’t give me a popup asking me to sign up to its newsletter.

When beginners need help with Git and they're using the CLI the first and best advice I give them is to stop using the CLI.

I don’t understand any of them. Normally even when I’m not really familiar with a tool, I have enough background knowledge to understand why it’s funny e.g. Scheme and Haskell jokes or something. I do use basic git regularly and all of this is over my head. I don’t know if that speaks to how complicated and unintuitive some of the advanced stuff is?

In any case, the refined version of that admission - the deliberate porcelain/plumbing distinction - is still best explained in the git docs and I wish more tools would copy it. apt(-get) has cautiously started that process, while GnuPG sadly remains a box shock full of surprises in both API and CLI.

This is actually kind of happening! (In a way)

There are, at this point, quite a few git-successors that either basically or literally use gits object model - git-butler, jujutsu, sapling (iirc). It's at worst good-enough.

I think at that point he only had the plumbing commands. Commands like "git commit" are the tools he meant.

As a primarily FreeBSD user who feels like I have to relearn the idiosyncrasies of practically the entire system every I install a new Linux distro, the mess of configuration options somehow actually seems entirely on-brand to me.

Which the parent poster said in their comment?

Yes, doesn't that match git's behavior? Or are you saying that's not the case?

Spot on. I had my repo messed up more than once. Sometimes it is quick enough to push that to GitHub.

You can set it in the config to whatever you want and the warning goes away.

The whole default branch name change was a terrible idea that caused many more problems than it solved—as was already pointed out at the time.

But if you're going to set a name anyway, may as well call it trunk, or dominatrix, depending upon today's silliness level.

Why?

There are advantages beyond avoiding the use of a charged term.

Every git repository hosting platform - GitHub, GitLab, Bitbucket, Codeberg - necessarily gives end users control over filenames.

"User-controlled strings as parameters" is not "access to your git" but it is still an attack vector.

You could use an illegal file name symbol as the Options Introducer?

Great lib. I meant libdog, a different thing. gitoxide is like "git implemented in Rust" while libdog is "git's necessary primitives in C" (objects, packs, sync proto, own index format, diff/merge, etc). As a result, gitoxide is 270KLoC while libdog is 24KLoC, plus 44KLoC of tokenizers. libdog uses token-level algorithms for diff, merge, blame. It also does syntax highlighting in the pager - they all need grammars.

Well it's a problem that's existed since day one

That's not the benefit of text, just adoption. All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same

How can text enable compabitility if you can't be certain how to parse it, and the rules can change any time??? Similarly with vendors - how can they lock you into themselves if you use some widespread open format?

Previously working command needs to continue behave the same way. Your original proposal was intended to provide backward compatibility (your third point in original comment), and that’s an important part of why it could work.

> Hmm, not sure I understand. How are those shell based?

A shell is just a programming language that's well suited for interactive repl use. Compare https://en.wikipedia.org/wiki/Scsh

Of course, Rust and Haskell aren't typically thought of as shells. Though if you wanted to and felt brave enough, you could use ghci as a shell.

> I guess my poorly worded claim was less focused on the OO nature of psh than on the typization (which both of these also do) - if you knew what type $rev and $path are, it's easier to distinguish intent, whether objects or not.

Agreed!

TeX uses -- (double hyphen) for producing an en dash and --- (triple hyphen) for an em dash, and that's pretty darn longstanding and well-established. And FWIW, the English writing conventions that I learned use em dashes as punctuation without an adjoining space—like this—but allow en dashes surrounded by spaces as an alternative – like this – so I frequently see spaced double hyphen used as the ASCII equivalent of dash punctuation and interpret it as the latter. I've never personally heard of double hyphen for em specifically, only either as en specifically or as a sort of ambiguous whatever-dash.

Then how do you type in an en dash instead? Also, according to LLMs, the en dash is used in far more languages than the em dash. Many languages don't use the em dash at all. Using the em dash for sentence interruptions seems to be specifically an US American English tradition: Most languages which use dashes for sentence interruptions use spaced en dashes instead.

On Linux, the en dash is typed with `[Compose]--.` and the em dash with `[Compose]---`.

because the double hyphen is a convention or placeholder for an emdash

A /more recent/ convention.

My memory of early Associated Press computer systems is that two dashes is the endash (or "nutt") and three dashes is the emdash ("mutt").