bash-it
bash-it copied to clipboard
Bash-it
aliases: Add new git-omz alias file
Description
Adds git-zsh alias file, with aliases copied from ohmyzsh. Currently there is no simple way of updating the aliases easily, and maybe we need to think about it.
Motivation and Context
Prompted by #1191, this is a re-iteration of #1201.
How Has This Been Tested?
Locally
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [x] My code follows the code style of this project.
- [ ] If my change requires a change to the documentation, I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [x] If I have added a new file, I also added it to
clean_files.txtand formatted it usinglint_clean_files.sh. - [ ] I have added tests to cover my changes, and all the new and existing tests pass.
Anyone else torn on whether we should use zsh-<whatever> vs <whatever>-zsh?
Anyone else torn on whether we should use
zsh-<whatever>vs<whatever>-zsh?
I went with git-zsh as I wanted to keep it close to the git alias, it makes more sense this way IMO
How will we keep this aligned with the Oh My Zsh project implementation?
In PR #1201 I tried to document a scripted approach. Would it make sense to do something similar here?
How will we keep this aligned with the Oh My Zsh project implementation?
In PR #1201 I tried to document a scripted approach. Would it make sense to do something similar here?
This is indeed a problem, as the plugin will not work right out of the box..
Simply seding the file will still not work, as the aliases sometimes use the $(git_current_branch) variable.
We might vendor it, and add a file in init.d vendor directory which explains how to update, and also defines the needed functions. It will be maintained by us, and when we update, we will change the file if necessary.
The workflow might be git-vendor + removing uneeded file + seding the wanted file + adding git-zsh loader that defines the needed functions and load the wanted file
How may approvals does a PR need? 🤪
haha, I still need to add some kind of script that updates this completion.. so its not ready yet. thanks for the CR though @bittner
I am also okay with vendoring it as it is right now- and update it once in a while. what do you think @cornfeedhobo @bittner ?
May I suggest that the new alias file be named git-omz? It's providing aliases from Oh My Zsh, not from Zsh itself. Just a nitpick... 😆
May I suggest that the new alias file be named
git-omz? It's providing aliases from Oh My Zsh, not from Zsh itself. Just a nitpick...
Nice idea- done!
Howdy folks!
I have added ohmyzsh as a vendored library using git-vendor with @buhl changes. this will hopefully be easier to maintain, although I still changed some code from the plugin so it will be loaded successfully
let me know what you think @cornfeedhobo @bittner @gaelicWizard
@NoahGorny I like it. The only question I have remaining is if you are open to the idea of applying patches to vendored libs and what that should look like. I still need to submit a patch to deal with pre-exec's clobbering of ignoreboth and ignorespace, and in the case of this PR, I'd rather not pollute the global namespace with the vaguely named is-at-least function.
The only question I have remaining is if you are open to the idea of applying patches to vendored libs and what that should look like. I still need to submit a patch to deal with pre-exec's clobbering of
ignorebothandignorespace, and in the case of this PR, I'd rather not pollute the global namespace with the vaguely namedis-at-leastfunction.
@cornfeedhobo, I've already submitted a PR upstream for preexec's history shenanigans, based on an existing PR that they had been ignoring. They did accept an unrelated PR for unbound parameters, but no traction on this one yet.
As for weird function names, we can handle that in our loader. I'll give it a go and post it here later tonight.
I'd like to suggest that it's quite valuable to avoid, whenever possible, carrying any patches over vendor'd libs. I like Homebrew's stance on this: only carry patches that are already approved or merged in an upstream dev branch. But, that said, it might not be entirely right for Bash It.
@gaelicWizard I think you saw my open issue with preexec. They aren't going to budge on this one. We either maintain a fork in our github organization, and patch that way, or figure out a scheme for patching on PR and documenting the diff.
@cornfeedhobo, I did a whole PR which keeps their desired behavior in place, but behaves properly when we change it. My idea was to let them have their way, and then we just set $HISTCONTROL back after we load them.
@NoahGorny I like it. The only question I have remaining is if you are open to the idea of applying patches to vendored libs and what that should look like. I still need to submit a patch to deal with pre-exec's clobbering of
ignorebothandignorespace, and in the case of this PR, I'd rather not pollute the global namespace with the vaguely namedis-at-leastfunction.
The problem with patches is that we need to apply them somewhere, probably during installation. We need to think about how we do this and how other places are doing it. Simply having patches around isn't going to cut it sadly. I also think that committing directly into the vendored file like I did isn't great, but it is the simplest solution currently
@NoahGorny Would you have a minute to resolve the conflicts of the PR and merge it, finally?
That would be great! :100:
Hello again :)
I asked this question a year ago and still would like to see this implementation merged into master.
Is there any chance of seeing this in the near future?