-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: run jj-*
commands in PATH
#3001
Comments
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 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 fwiw, shell aliases could be faked if we had |
What do you mean by "shell aliases could be faked"? By |
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 ..."] |
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".
what benefit does that have over running things in path? it seems more annoying to setup because of the boilerplate.
👍 |
The boilerplate is yeah annoying. It's just one way to fake shell aliases. We might want better syntax like |
well, they are interesting to me, or i wouldn't write them. if i didn't want oh, i suppose that's an argument in favor of making it an alias so |
I mean |
If going down the route of I think both plugin commands and No idea why but for cargo, the plugins are invoked as 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 |
I dislike randomly running stuff in 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 #170 gets implemented i have a |
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 Now, I do think there's room for improvement if you do want to let people provide a |
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. |
can you give a concrete example of how to make |
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 |
i'm having a really hard time understanding why you think "single command" aliases should be natively supported but "multi-command" aliases shouldn't. |
By clicking through all the interlinked issues and discussions, there are a ton of ideas with various degrees of overlap. Many of them are very powerful and hard to implement, like extensions that communicate with a grpc server. But Yuya's idea of For the originally requested feature, it adds a trivial line of boilerplate to the config. But anyone who is configuring their CLI tools to this degree probably has a dotfiles repo anyway, so not an issue. It also has distinct benefits:
Sounds cool, but I don't think this should stop us from getting the immediate win of Yuya's idea. If a team can already agree on using jj, they can also agree on installing a cross-platform shell. We (sadly) don't live in a world where everyone is already using jj and expects to be able to clone an open-source repo and use the project-specific jj aliases without having to install any additional tools. The primary use case here is for individuals to streamline their own workflows. This is perfectly solved with Yuya's idea. Stuff your entire workflow in a simple bash script and add a single line to your jj config.
This is dismissing the previous discussion. The shell cannot redirect
I'm not a security expert, but if a malicious actor is messing with your config files and putting random binaries in your This is very easy to implement, PR incoming. |
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
ranjj-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
The text was updated successfully, but these errors were encountered: