jj
jj copied to clipboard
jj-vcs
FR: run `jj-*` commands in PATH
Is your feature request related to a problem? Please describe.
i want to add an alias that involves multiple jj commands (specifically jj branch set main -r @- && jj git push). currently, it's not possible to run multiple commands in aliases, because there's no equivalent of git's ! feature to run things in the shell.
Describe the solution you'd like
that's ok, i'm not asking for it to be changed, but it would be nice if instead jj push-head ran jj-push-head in PATH, so i don't have to remember which commands are aliases and which are shell helpers.
Describe alternatives you've considered add support for shell execution in aliases
Additional context jj 0.13.0-81b0e3bf3bf6f230740e93532b9a9767e8a4ef6e
err actually i'm going to wait to work on this until i hear back that it's a desired feature
My solution to this is that I put various scripts called jj.tool, jj.watch, jj.logstatus in ~/.local/bin.
I think this is still a desired feature? I am not actually sure. I don't see an obvious need for it for myself, but it seems expected, and I don't see any harm in it.
We should probably ask the Git folks what they think. They would know if it's caused the Git project any problems. They can probably also help point out any non-obvious benefits.
I slightly prefer shell aliases than jj-<subcommand> lookup in PATH, but I don't know why modern tools like cargo do that.
fwiw, shell aliases could be faked if we had jj util exec/sh-c [ARGS] subcommand.
fwiw, shell aliases could be faked if we had jj util exec/sh-c [ARGS] subcommand.
What do you mean by "shell aliases could be faked"? By jj util exec, do you mean executing a command in the repo root as opposed to anywhere?
What do you mean by "shell aliases could be faked"? By
jj util exec, do you mean executing a command in the repo root as opposed to anywhere?
Yes, just exec or shell out with some environment variables set, and the alias will be something like
[aliases]
shell-alias = ["util", "exec", "sh", "-c", "$JJ ..."]
I slightly prefer shell aliases than
jj-<subcommand>lookup inPATH, but I don't know why modern tools likecargodo that.
shell aliases can't use spaces, so like @ilyagr found the commands have to be named with some other separator like periods or underscores. that's what i meant by "i don't have to remember which commands are aliases and which are shell helpers".
Yes, just exec or shell out with some environment variables set
what benefit does that have over running things in path? it seems more annoying to setup because of the boilerplate.
We should probably ask the Git folks what they think. They would know if it's caused the Git project any problems. They can probably also help point out any non-obvious benefits.
:+1:
what benefit does that have over running things in path? it seems more annoying to setup because of the boilerplate.
- alias commands can be inlined in config file
jj[TAB] won't list those uninteresting commands
The boilerplate is yeah annoying. It's just one way to fake shell aliases. We might want better syntax like ! in git.
jj[TAB] won't list those uninteresting commands
well, they are interesting to me, or i wouldn't write them. if i didn't want jj <TAB> to complete them i would make them shell functions instead of aliases.
oh, i suppose that's an argument in favor of making it an alias so jj util completion doesn't have to search PATH :thinking:
I mean jj<TAB> (not jj <TAB>). It's a bit annoying that git<TAB> doesn't insert space because there are many git- extension commands which are supposed to be executed as git <subcommand>.
If going down the route of ! support, it might be worth looking into an embeddable shell so people can get some basic cross-platform support. A more basic option is deno_task_shell and duckscript for a more advanced option. I've also been tempted to write an embeddable version of nushell.
I think both plugin commands and ! are useful. ! is great for very lightweight needs with plugins for more complex or more easily shared needs.
No idea why but for cargo, the plugins are invoked as cargo-<plugin> <plugin>. I guess this can help if you want to have a multiple-role binary like busybox. It does cause a lot of confusion and makes it more difficult to run outside of being a plugin.
I can see the auto-completion pain point. I wonder if the way to handle that is by having to register the plugins by defining a ! alias. We could define a non-PATH location for people to put their plugins that we expose as an environment variable to the ! shell.
I dislike randomly running stuff in PATH and find Yuya's proposed solution better. Mostly because running stuff prefixed with <cli-tool>- is a neat hack and a very non-portable way to customize the binary which jj already allows.
If we can come up with a good design for plugins, maybe it'd support it, but this isn't something we're discussing right now.
another use case for running multiple jj commands at once: until https://github.com/martinvonz/jj/issues/170 gets implemented i have a jj-absorb() { ... } shell alias in .profile, it would be nice to spell that as jj absorb (whether that's with a jj util exec alias or just running things in PATH).
We should probably ask the Git folks what they think. They would know if it's caused the Git project any problems. They can probably also help point out any non-obvious benefits.
Howdy, Git folk reporting :)
I don't think it's caused any problems. The biggest potential one I can think of is namespace collision - what happens to users who have their own custom git-amend on $PATH when we decide to implement a first party git amend? But in that case we either add it to the C monolith, which means the user's git-amend never has an opportunity to be found, or we add it to the git exec dir alongside scripts like git-submodule and git-send-email, which also gets searched before $PATH does.
Now, I do think there's room for improvement if you do want to let people provide a jj-foo in $PATH - for example, you could provide them some pertinent info about the repo via envvars if you wanted, or you could check for collisions and log some warning (rather than silently ignoring their thing and running your thing). But overall it's been a pretty nice accidental-feature for us, IMO.
The jj absorb feature should probably be a first class feature in the jj library so that it can be used in other environments beyond the CLI. If this is implemented as a separate program or script then it can't be used in Web based IDEs, since those typically don't have a local file system and can't shell out.
Also arbitrary program execution won't pass a security review for a server deployment, so this feature would have to be disabled when the jj lib is deployed on a server.
So the initial use case for jj absorb is probably not the most compelling justification for this feature request, in my opinion.
In general, aliases and functions and PATH discovery really are the responsibility of the shell and not the responsibility of a version control system, in my view, so this feature would be out of place.
Also this being an accidental feature in Git ends up not offering a compelling reason in terms of preexisting art.
In summary, I think there's little compelling reasons to copy this feature from Git into jj.
In general, aliases and functions and PATH discovery really are the responsibility of the shell and not the responsibility of a version control system, in my view, so this feature would be out of place.
can you give a concrete example of how to make jj <TAB> work with aliases with only support from the shell?
I think that will depend on the shell. For example, for Bash, I'd look into the Bash completion files / bash_completion.d directory.
jj natively supports bash completions with jj util completion. are you suggesting completely scrapping that and writing my own completions from scratch?
i'm having a really hard time understanding why you think "single command" aliases should be natively supported but "multi-command" aliases shouldn't.