upvote

points

by SV_BubbleTime9 hours ago |
comments
upvoteby steveklabnik9 hours ago|
[-]
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.

reply
upvoteby SV_BubbleTime8 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”

reply
upvoteby steveklabnik8 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.

reply
upvoteby SV_BubbleTime6 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.

reply
upvoteby steveklabnik6 hours ago|
parent|
[-]
If you're happy with git, you should keep using it.
reply