You're right that, looking solely at `init`, a flag could make sense to choose the backend.

The bigger picture here though: `jj git` is the subcommand that prefixes all commands that are git specific, rather than being backend agnostic. There is also `jj git clone`, `jj git fetch`, `jj git push`, etc.

For a different backend, say Google's piper backend, there's `jj piper <whatever>`.

This means that backend specific features aren't polluting the interface of more general features.

▲

SV_BubbleTime 8 hours ago | parent [-]

>There is also `jj git clone`, `jj git fetch`, `jj git push`, etc.

If the compatibility isn’t automatic… why would I bother with jj commands here at all? “Git with extra steps”

▲

steveklabnik 7 hours ago | parent [-]

The on-disk repository compatibility is automatic. But if you're trying to fetch something via a specific protocol, you use the command for the protocol you want to use.

There is no extra step between `git push` and `jj git push`, they're both one step.

▲

SV_BubbleTime 5 hours ago | parent [-]

I meant the extra step being why would I bother with jj if I’m having to specific gut inside of jj?

The issue is pretty obvious to me. GIT is the standard and that likely won’t change for some time. So if jj makes my git life better, awesome, but it’s just a wrapper and I need to know all the git voodoo now with jj voodoo on top, I don’t quite get it.

	▲	steveklabnik 5 hours ago \| parent [-]
		If you're happy with git, you should keep using it.