1. Pagination with a pager is a reasonable default. See `git log`.

2. The native format would be `jj init`. For precedent, see how uv dealt with its pip compatibility: `uv pip install` was obsoleted by `uv add`.

▲

SV_BubbleTime 8 hours ago | parent [-]

1. No one with good vision would give a single feature two names. It’s dumb. Here is our pager feature. Cool, how do I access it? Oh you set the ui.paginate options of course!!

2. It’s almost like we have some established ways to denote arguments that are pretty popular… ‘jj init —-git’ for example? By using ‘jj git init’ I would expect all of the git compatible commands to be be ‘jj git xxx’ because that is a reasonable expectation.

This is a problem with the voodoo. These obscure nonsense commands only makes sense when you are accustomed to them. If there’s no reasonable expectation that you could just figure it out on your own. Go on vacation and come back and be surprised when you forget the voodoo. Not to mention that every tool has to have its own unique voodoo.

Almost like the professional world has figured out that made by software engineers for software engineers will never be popular. And then engineers don’t understand the effects of why you might want tool to be intuitive and popular.

▲

steveklabnik 8 hours ago | parent [-]

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 6 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.